PID in continous task

[Ken Roach]

Also: I have definitely seen this before, and not just in the ControlLogix.

I converted a plant that ran its PLC-5 PID loops every scan but configured them for around 100 ms update time and they worked... because the PLC-5's were heavily loaded and their scantime was about 100 ms.

When we converted to ControlLogix and the scantime dropped to 5 to 10 ms, of course all the loops went wild.

The quick fix was to correctly put a timer bit in front of every PID instruction that slowed down their execution to the rate for which they were actually configured and tuned.

 

[Thomas R/T Chally]

These are just regular PID, not PIDE. There are no timers in the PID subroutine. Each PID control block is on a rung by itself. This is all excellent information. Thank you for your input. I will have to get with the plant engineers to see what they want to do.

 

[amberman]

My colleague has been putting PIDs in continuous tasks with no timers for years. They work well enough and although I put timers in when i write software (I find putting them in periodic tasks males the code messy) I can't pretend there are better results. I'd raise the issue but if the PID is working ok I'd leave it alone. It's unlikely the scan time will ever significantly change I'd guess??

 

[Ron Beaufort]

for those who would like a better understanding of how the PID can still be tuned to work reliably - even when programmed in an improperly timed situation - the following link about Bubba's paycheck might be helpful ...

http://www.plctalk.net/qanda/showthread.php?p=73610&postcount=10

.

 

[daba]

for those who would like a better understanding of how the PID can still be tuned to work reliably - even when programmed in an improperly timed situation - the following link about Bubba's paycheck might be helpful ...

http://www.plctalk.net/qanda/showthread.php?p=73610&postcount=10

.

but the first paragraph in the linked post seems to contradict what you suggest ...

"it is possible to “compensate” for a PID which is being executed on an inaccurately controlled schedule ... we can do this by altering the Ti setting to counteract either a “too fast” or a “too slow” execution rate ... we can do this (and this is the most important part) AS LONG AS the execution rate remains CONSISTENT"

Let it just be said that...

1. PID instructions executing in the normal scan without a triggering timer is "worst-case". Adding or deleting large amounts of code will severely affect the tuning, because the PID execution rate will change dramatically. You will even affect the PID tuning by going online with Studio/RSLogix5000 depending on the settings of the System Overhead Time Slice.

2. PID instructions executing in the normal scan with a triggering timer is acceptable in most cases. Adding or deleting large amounts of code will not "severely" affect the tuning, except on very fast loops. Larger scan times inevitably reduce the accuracy of timers.

3. PID instructions executing in a Periodic Task will give you the best chance of tuning a difficult loop, and making that tuning "future-proof". Adding or deleting large amounts of code will not affect the tuning at all. Going online to the controller, even with multiple users, will not affect the tuning.

amberman believes that putting PIDs where they ought to be "makes the code messy". I have to disagree, it's no more "messy" than segregating your code into routines. I think I need to add that only the PID instructions themselves need to be in a periodic task, the rest of the "glue logic" can be programmed in the continuous task.

PID is an instruction that definitely needs to be scanned at a CONSISTENT rate, and that rate needs to be set into the .UPD element of the PID tag. I would also advocate that the .UPD is updated automatically, by GSVing the Periodic Task rate, and writing it to the .UPD of all the PIDs in the Periodic Task. If anyone changes the task rate, the PIDs will be notified, and do their calculations accordingly.

I've worked on systems with many PIDs in one controller, and those systems have been modified many times over the years, new control routines added, some deleted, etc., and no PID retuning has been needed, because nothing changes the rate at which the PID instructions are scanned.

 

[ASF]

When I was still fresh into PLC programming, I wrote a couple of PID loops into a continuous task with no timer or any other means to schedule them. Tuned them up and got them working great! It was a pretty slow moving loop which didn't get too much disturbance so I went on my way happily. A year later I was looking through the help file for the PID instruction and noticed the scheduling/periodic task recommendation, so I went back and moved the other PID's I'd done previously into the periodic task. Well, that was a fun morning. As everyone here could probably guess, that PID went to hell in a handbasket very quickly. I got it tuned up again eventually, but yes, the values were dramatically different to what they had been in the continuous task.

You've got some great advice above from people who know a lot more about PID than I do, so I won't confuse the issue any further on the practicality side, but just wanted to share that to illustrate that all the advice given here is bang on