Yo, Peter N,
Again, I take no offense at what you said about “slowing down the PID” - but I’m really trying to find out what I said that you interpreted that way. I went back over my previous posts. Is this it?
Let’s just suppose that you (incorrectly) execute the PID every single time that the rung gets scanned. That’s really too often.
If that’s what you’re talking about - then I still respectfully stand by what I said - but please let me elaborate.
Many beginners try to put their PID instruction on an unconditional rung. In many situations that results in the PID executing its math equation each and every time that the rung gets scanned. Now - that’s pretty darned fast. Not that there’s anything wrong with “fast” - except that, when controlling a system with a slower response, going “fast” just unduly burdens the processor with mathematical “busy” work. Still, if “the PID is hogging the scan time” isn’t an issue (and it rarely is) - AND if the “loop update time” and the actual PID “execution time” COULD be synchronized - then this “unconditional rung” strategy would work OK. But a problem arises when we start to consider the actual time which elapses between successive executions. If the rung is unconditional, then the time between successive PID executions is solely dependent upon the scan time. And that amount of time CAN fluctuate from scan to scan - depending on true/false logic, etc., etc.
Now in practice, diehard technicians CAN get the PID to work with this “unconditional rung” setup. If they tinker around long enough with the tuning parameters - and also with the loop update time - they can eventually (well, usually) get the loop tuned for adequate control - even though the PID is being executed at an extremely fast rate. But sooner or later - something causes the scan time to increase significantly. Usually this is caused by additional ladder rungs, more subroutines, etc. being added to the program. That increases the processor’s scan time and - as you well know - causes the loop to lose its tuning. Which is what I was getting at when I said:
Plus - even worse - the elapsed time between successive scans might vary considerably from scan to scan.
Faced with this situation, the technician usually grumbles something along the lines of “piece of junk won’t stay tuned” and goes back to tinkering with the settings.
As many of you know (from my user profile) I work as an “inside technical support” person for an Allen-Bradley distributor. One of my job duties is fielding customer phone calls for technical support. Whenever you see lengthy posts like this it usually indicates that “all is well” out there in the field - and I’ve got time to type between calls. Anyway -
Whenever I have a customer call in about a PID problem, the very first two things that I ask about are: (1) the “loop update time” setting - and (2) the conditions being used to “trigger” the PID’s execution. In the VAST majority of cases, these two conditions are not set up correctly. Once the customer has these two items properly set up, then they have a fighting chance of being able to tune the loop. Conversely, if these two conditions are NOT set up properly, then the chances of finding a satisfactory solution to the customer’s PID problem are very slim indeed.
Look at a typical complaint from the customer’s point of view. Let’s say that we have a machine with PID control which has been adequately tuned and running along fine for several months - with absolutely no problems. Now, all of a sudden, the machine is “out of tune” and we’re wasting product. We haven’t touched the tuning values - or altered the control for the machine in any way. And the machine itself hasn’t been changed either. So what’s suddenly causing the problem?
How about that ladder logic program addition for a new (totally unrelated) piece of equipment? A large number of new rungs were added - and most of them contain extensive math operations - and other features which are “scan time” intensive. So the processor’s scan time has been increased. But that won’t affect the PID will it? If the PID were set up right it wouldn’t - but this customer just happens to be operating his PID on an unconditional rung. The tuning values he’s been using were based on the elapsed time between successive scans of the PID. But - and here’s the trick - now (due to the large program addition) that elapsed time between successive scans has increased - so the old tuning values aren’t quite right anymore. Specifically, the Integral action and the Derivative action (which both take the execution time into mathematical consideration) are now skewed from their original effects on the controller’s final output. And so the plant’s production is suffering. So the technician grumbles something along the lines of “piece of junk won’t stay tuned” and goes back to tinkering with the settings.
One point I’d like to make is: As soon as ANY type of “tuning” issue arises, the first thing we invariably hear is “should I increase the integral ...” or “should I decrease the derivative” and so on - and so on.
Sometimes it’s like trying to help someone troubleshoot “I can’t get the car to start” over the phone.
“The car won’t start so we replaced the spark plugs. We replaced the ignition coil. We shaved the cats. We girdled the oak. We took the wheels out and put butter in. Nothing helps. So what do we try next?”
“How about the gas? Are you sure that you have gas in the tank?”
“Hold on - let me check. OK, thanks, we got it working now.”
And - yes - it usually ends up that adjustments to the integral - or to the derivative - really are necessary. BUT! - if the “loop update time” and the PID’s execution “trigger” aren’t matched up FIRST, then the necessary adjustments to the tuning parameters are EXTREMELY difficult (if not impossible) to make. On the other hand, once the “loop update time” and the PID’s execution “trigger” ARE correctly matched, then a lot of other problems seem to become much more manageable.
Specific case in point: We had a customer recently with four identical pieces of production equipment - each one was controlled by a separate PID - all in the same PLC program. The customer was annoyed (to put it mildly) that there was absolutely no consistency for the tuning values from one system to the next. I mean they weren’t even close. The settings for Kc, Ti, and Td were all over the board. The plant technicians wanted them all to be set the same from one machine to the next - or at least close to the same - to make it easier to troubleshoot.
You know what’s coming next. We took a look at the “trigger” timer Preset settings. Three of them were at 100 (correct for this application) - but one of them had been incorrectly set at 1 - so it was, in effect, executing 100 times “faster” than its brothers. Next we looked at the “loop update times” for each PID. These were all up, down, and in the middle - and (if memory serves) I don’t think that any one of them matched the “trigger” time interval. So we recommended that the customer first correct these settings - and then retune the systems. As it turned out, they only needed to retune one of them. Once they came up with a set of “good” turning settings, they plugged these into the other three PID’s as a “starting point” for tuning - and everything else just sort of fell into place.
And so, Peter, there IS a point which I have been trying to make - and apparently from your posts in a couple of threads - I’m failing miserably in making myself understood. Now I KNOW that you understand these issues - undoubtedly far better than I do - but still it looks (based on how I read your posts) that you’re interpreting my observations on the “loop update time” and the PID’s execution “trigger” as either trivial (which I doubt, because you of all people would know that they are far from trivial) - or else I’m not making myself very clear on the thoughts which I am trying to convey (very likely - although I’m trying really hard).
Anyway, those are the basic “timing issue” ideas that I meant to convey. I apologize if I didn’t make myself clear. I certainly didn’t mean to imply that a “slowed down” PID would give BETTER control than a “fast” one. Personally, I’ve never seen that happen. Of course in this sense, I’m using the terms “slow” and “fast” in referring to the elapsed time between successive executions of the PID.
And in that same sense, I HAVE seen situations where a PID - which was being executed on a “fast” schedule - could be “slowed down” to a more conservative schedule. Granted, the control never got any BETTER - but it didn’t get any worse either.
Note to SLC people: In the SLC platform, you MUST (thank you, Allen) put your PID on an unconditional rung. You may then select the “Timed Mode = TIMED” setting. The PID will then automatically be scheduled at whatever time you have entered for the “Loop Update” setting. Notice that in this thread we’re not working with an SLC. This thread is concerned with the PLC-5 platform and the PID is somewhat different with these larger processors.
Now a note to Tom Jenkins: If I understand you correctly, then part of your personal PID tuning strategy is to increase and decrease the “loop update time” setting - without changing the operation of the external condition which is used to “trigger” the PID into execution. (Usually this is a timer done bit.) I think this is one of the senses in which you are using the terms “speed up” and “slow down” the PID. I have no intention of trying to argue with your success. That having been said, I know that you will fully understand what I’m about to say in my next post. (I ran out of room in this one.)
