Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on April 11, 2020, 03:39:15 PM
-
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.)
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 - 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."
-
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 ;-)
-
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.
-
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.
-
Just to back up my post here is a short SIM program. No unanticipated off outputs in cycle.
TIMEPROP cycle time 5.0 seconds
Source value (simulated PID output) changing once per second
Loaded in to 'Continuous Input' (R0) on leading edge of C0 output
Not quite the same as BobO's example - only loaded on leading edge of output bit
Sorry, please change NO of ST4 to rising edge ST4
Problems with this if 'Continuous Input' goes to 0.0 or 100.0 - added a CLAMP 0.1 - 99.9 before moving
-
I added code to synchronize. It'll be in the maintenance release due out in a day or two. We have to release another patch to fix some analog initialization issues anyway.
It isn't perfect. It will still glitch on run mode program updates. To make it perfect would require about 10x the effort. I care, but not that much. ;)
-
Thanks, Bernie and BobO.
I see Bernie caught the 0 or 100 hang before I got back from testing these in the sim. Rather than the clamp, I put an OFFDTMR around the MATH with a falling edge timer contact around the rising edge TIMEPROP output. Then if it goes too long or on first run, it "watchdogs" the input update. Except for that, Bernie's example works fine (the ST4 seems OK regardless of contact type) and I am truly puzzled because I thought I had already tried this suggestion.
BobO's will hang for the same conditions. I see this one running without the extra transitions also, but I'm pretty sure I don't understand why the second branch doesn't cause an issue.
Regardless, if I can keep the TIMEPROP I'll be happier, I didn't mention some of the zones are heat AND cool, and the fans are on contactors. Plus they need to come on, and stay on longer, the more the PID output is below 50%. I was looking at LERP to solve some of that scaling, but the TIMEPROP is cleaner.
Thank you Bob! I would really appreciate this. A minor glitch on run transition is not a big deal.
-
Thanks, Bernie and BobO.
I see Bernie caught the 0 or 100 hang before I got back from testing these in the sim. Rather than the clamp, I put an OFFDTMR around the MATH with a falling edge timer contact around the rising edge TIMEPROP output. Then if it goes too long or on first run, it "watchdogs" the input update. Except for that, Bernie's example works fine (the ST4 seems OK regardless of contact type) and I am truly puzzled because I thought I had already tried this suggestion.
BobO's will hang for the same conditions. I see this one running without the extra transitions also, but I'm pretty sure I don't understand why the second branch doesn't cause an issue.
Regardless, if I can keep the TIMEPROP I'll be happier, I didn't mention some of the zones are heat AND cool, and the fans are on contactors. Plus they need to come on, and stay on longer, the more the PID output is below 50%. I was looking at LERP to solve some of that scaling, but the TIMEPROP is cleaner.
Thank you Bob! I would really appreciate this. A minor glitch on run transition is not a big deal.
I had clamped R0 at 10-90 to prevent the hang.
-
It isn't perfect. It will still glitch on run mode program updates. To make it perfect would require about 10x the effort. I care, but not that much. ;)
Run mode transitions are rare enough it doesn't really justify putting any effort into it.
-
SUPER!
Two hours after I installed v2.7.2 (due to crashes when editing rung comments in v2.7.1 (probably too many VMs open)) I opened another instance of DmD and was told v2.7.3 was here.
This looks to totally resolve my needing to do anything but just use the instruction. This is great because this system is already being installed and startup will be in the next few days.
Thanks Bob and all!
BTW, AutomationDirect has changed their download page since yesterday afternoon when I download v2.7.2 .
-
SUPER!
Two hours after I installed v2.7.2 (due to crashes when editing rung comments in v2.7.1 (probably too many VMs open)) I opened another instance of DmD and was told v2.7.3 was here.
This looks to totally resolve my needing to do anything but just use the instruction. This is great because this system is already being installed and startup will be in the next few days.
Thanks Bob and all!
BTW, AutomationDirect has changed their download page since yesterday afternoon when I download v2.7.2 .
You're welcome!
-
BTW, AutomationDirect has changed their download page since yesterday afternoon when I download v2.7.2 .
We "released" it to ADC yesterday. They are getting real good about updating their download pages!
-
Their download page "experience" was what I was referring to. Their new forum is up also. But yes, they did tend to be behind a little, at times.
-
Their download page "experience" was what I was referring to. Their new forum is up also. But yes, they did tend to be behind a little, at times.
Both 2.7.2 and 2.7.3 got up there in the same or next day. Considering they are working on the new "community" website, this was great!