TIMEPROP Chatter

[Mike Nash]

I am seeing the TIMEPROP output chattering (one or more quick Off-On transistions) when it should be turning off. This only appears to happen when the "Continuous Input" value is changing, especially by a large percentage.

I see mention that the PID.Output should be relatively smooth, but this is not always the case, especially with Rate or even just a high gain and a setpoint change.

It's easy to see it here:

STR ST1
MATH R0 "RANDREAL() * 100"

STR ST1
TIMEPROP 2000 R1 0.0 100.0 C0

In 2 seconds, I get around 300-400 transitions (in the simulator).

If I FILTER the TIMEPROP input value, it gets better, but a contactor still wouldn't be happy.

I see this with a PID.Output, even if the PID.SampleTime is 10 times longer than the TIMEPROP cycle time. This is usually when the PID.Output swings due to Rate (Derivative) or setpoint change. It may only chatter 2-3 times here though.

Any advice?

(The sample code was just to verify that input changes during the cycle time can affect the output immediately.)

(P.S. I though I lost this whole post, thankfully, Ctrl-Z got it back.)

[franji1]

Q1: What is the sample time of your PID instruction?
Q2: What is the "cycle time" of your TIMEPROP?

If they match, the discrete will cycle be a straight percentage of the PID.Output
If the TIMEPROP cycle time is greater than the PID sample time, you will see strange results since the instruction's percentage will be changing within a single "cycle".
If the TIMEPROP cycle time is less than the PID sample time (say half or 1/4, this could actually be good in that you would be making your discrete a little more "analog" behavior in that you would get 2 or 4 cycles at that same percentage.

For example, if the PID Output was 50% and TIMEPROP cycle time matched the PID sample time, the discrete output would be ON for 50% of the PID sample time.

If the TIMEPROP was half of the PID sample time, it would be on for 25% of the PID sample time, then OFF for 25%, then ON for 25%, then OFF for 25%, spreading out that 50% Output across 2 cycles of the TIMEPROP instead of 1 cycle.

You might even do MATH on the TIMEPROP cycle time based on the PID.SampleTime structure member, either making it equal to, or 1/2, or 1/3, or 1/4 (definitely not LARGER than the PID.SampleTime).

[Mike Nash]

Well... playing in the simulator some more, as long as the PID output isn't wild, I am seeing decent outputs on the TIMEPROP. It will definitely get crazy if the input jumps too much, but after "tuning" my loop, it looks OK.

The only issue with the TIMEPROP being too short is trying to display current draw for the heaters. HMI update rate is pretty much going to miss reading anything, or make it look like they are always on at times.

Thanks for the feedback. I think I was assuming the TIMEPROP would sample the input at the start of the cycle period and not try to "do things" in response to input changes otherwise.

[b_carlton]

Maybe apply a new percent ON time into the continuous input at the beginning of the TIMEPROP cycle time. I'll assume that the output turns on at the beginning of the TIMEPROP's cycle. Just one-shot the TIMEPROP's control output and use that to move a new value into the TIMEPROP's continuous input. Obviously you'll have to move some non-zero value into the control to get it going. If the TIMEPROP actually turns on the output in the last portion of the cycle time then use the falling edge to apply the new value.

A more involved solution would be an option within the TIMEPROP instruction itself to latch the continuous input value at the beginning of each cycle.

[Mike Nash]

I've just tried a bunch of different things as far as sampling and holding before the value goes to the TIMEPROP, but there are still times when the cycle time does not make the full duration without the output going off and coming back on. With that said, trending a timer accumulator where the timer is reset whenever the TIMEPROP output turns on (rising edge) shows the cycle time as a whole is not less, just that there are multiple short cycles within that time period.

Looking at the trends, I am seeing that if the TIMEPROP Continuous Input changes after the output has turned on or off, it will immediately calculate a new on/off cycle for the remainder of the cycle time, turning the output back on and off (or off early). Sort of a sub-cycling.

The screenshot shows where the ActualTime is reset at the leading edge of the Output. This effect looks minimized when you have 10 cycles per timeprop cycle time, but it is always there. The short cycles always add together to equal the cycle time.

I have to assume this is intentional, but I am not sure it is what I need to be happening.

[BobO]

TIMEPROP is designed to be used with loops, and in general, the CycleTime should be significantly less than the SampleTime of the loop...like 1/5th, or even 1/10th. If your loop is changing faster than TIMEPROP can reasonably function, use a hardware PWM.

[Mike Nash]

It is very much the opposite. These will be heaters with a verrrry slow response time. I just didn't expect to see the cycle time being "violated" during input changes. The ratio of on to off time is being applied to the remainder of the cycle time immediately if there is a change. So I could see a real world device being asked to cycle on-off more than once per 10 second period for example. Some things care about this.

I'm not saying TIMEPROP is wrong, as I could imagine places this would be fine. But this is much more response than I need or desire for this application.

[Controls Guy]

Why focus so hard on TIMEPROP per se?  We've been writing our own from scratch for decades now.  If it doesn't do what you want, you can whip up your own in like five minutes.

[BobO]

It is very much the opposite. These will be heaters with a verrrry slow response time. I just didn't expect to see the cycle time being "violated" during input changes. The ratio of on to off time is being applied to the remainder of the cycle time immediately if there is a change. So I could see a real world device being asked to cycle on-off more than once per 10 second period for example. Some things care about this.

I'm not saying TIMEPROP is wrong, as I could imagine places this would be fine. But this is much more response than I need or desire for this application.

The entire purpose of TIMEPROP is to approximate analog control with a discrete signal. It's a dimmer. The shorter the CycleTime, the more analog the result. It is commonly used with temperature control, and works beautifully.

If that isn't acceptable, I'm sure we can suggest other ways to solve the problem.

[Mike Nash]

Controls Guy - Because I already have it in the program a "bazillion" times? I'm just glad I caught it before startup, because it would have had me scratching my head if things had gotten weird. I'm not a temp control guy.

Yes, I have an alternate version already figured out now. It's just a shame as it is a compact instruction, vs MATH and timers.

BobO - I finally realized the analog imitation was the purpose, but that's not really very clear in the help. And what is the purpose of the cycle time if it is sometimes ignored (sort-of)?

If I have an analog AC ammeter in a heater circuit swinging wildly, it's going to be an issue. A CT back into a PLC/HMI and I'm not going to get anything usable to display. So, I need a nice predictable pattern.

[Controls Guy]

Use pointers.  Put the math in a FOR loop or use the PLC scan as a loop and handle consecutive heaters one per scan..  That'll save bulk, plus give you a single spot to make algorithm changes.

I know what you mean about the "test first, THEN replicate" thing.   I'm always trying to remember, is it "measure once, cut twice..."?

[BobO]

BobO - I finally realized the analog imitation was the purpose, but that's not really very clear in the help. And what is the purpose of the cycle time if it is sometimes ignored (sort-of)?

If I have an analog AC ammeter in a heater circuit swinging wildly, it's going to be an issue. A CT back into a PLC/HMI and I'm not going to get anything usable to display. So, I need a nice predictable pattern.

The cycle time is never being ignored, but when the calculated ON period keeps changing because the input is changing constantly, it can be constantly switching on and off. Let's say the CycleTime is 10 seconds. At 2 seconds and 30% it is on, but at 2.1 seconds and 20% is it now off, and again, at 2.2 seconds and back to 30% it is back on. It is mostly stateless, other than the cycle timer.

From the help: "Cycle Time - specifies theamount of time that will be divided into the ON and an OFF portions. This values should never exceed the Sample Time of the PID Loop that is generating the continuous input value. When determining this value, a value that is 1/10 of the Sample Time of the PID Loop is a good starting point. The closer this value is to the PID Loop Sample Time the longer it takes for changes the Loop's output to show up in the TIMEPROP's output."

[Mike Nash]

We seem to have conflicting ideas of what a cycle is. I read all the help and it still happens that at 1/10 the PID Sample Time, there are glitchy transistions. I see no way to sync the TIMEPROP timebase such that this never occurs.

Is it a real problem? Probably not, but I don't want more than two edges in a cycle time period.

Since I'm not using it as intended, I'll drop back to using more conventional instructions. Except MATH, I always find a place for MATH ;-)

[Controls Guy]

In general I agree, there should only be one pulse per timebase and the proportioner should be agnostic of the input except once per cycle.  I think most of us consider that the definition of a timebase.  That's the only way I've ever written one.   Nevertheless, it's so easy to write, I can't get too exercised about what some particular instruction does.

[BobO]

We seem to have conflicting ideas of what a cycle is. I read all the help and it still happens that at 1/10 the PID Sample Time, there are glitchy transistions. I see no way to sync the TIMEPROP timebase such that this never occurs.

Is it a real problem? Probably not, but I don't want more than two edges in a cycle time period.

Since I'm not using it as intended, I'll drop back to using more conventional instructions. Except MATH, I always find a place for MATH ;-)

You're right. It isn't synchronous and wasn't intended to be. That's more storage and more complexity for effectively zero change in result.

One rung should fix it. R0 is my simulated loop output. R1 is the input to my TIMEPROP. C100 is the TIMEPROP's output.