PID in continous task

I was going over the code for one of our process unit and discovered that our PID loops are in the continuous task. I know they are usually placed in the periodic tasks with the same update time as the PID instruction. The unit has been running for many years like this and I was wondering if there would be any improvement in placing them in the periodic task vs them being in the continuous task?

What are the scan times? What is the period?

I am assuming the PID is triggered by a timer, and in most cases this is OK, but not ideal.

The PID instruction calculates everything based on the incoming data change versus the time elapsed since it was scanned.

Always best to make the instruction scan at the same time interval, so I always put PIDs in a periodic task...

if you know what you are doing and adjust the parameters later, of course there could be an improvement.

but if you don't, and just move it to periodic task, you could have problems. it is luck and obviously stable cycle time that it works ok now, but better that, then you screwin it up...

(if you don't wan't to mess with parameters, set up a periodic that is near your usual cycle time, it shouldn't work worse..)

What are the tuning parameter values?

I had a similar situation years ago, while it 'worked' we needed tighter control, and being in the continuous task the tuning values were really really far-out, I have always wondered how the OEM got it to work in the first place.

After moving it to a periodic task, I got tigher control much easier. Helps to graph the SP, PV and OP valves to see how well the PID loop is actually performing.

JeremyM said:

What are the scan times? What is the period?

Click to expand...

I'll have to check the scan time when I get back to work tomorrow. Loop update time is set for 200ms.

daba said:

I am assuming the PID is triggered by a timer, and in most cases this is OK, but not ideal.

The PID instruction calculates everything based on the incoming data change versus the time elapsed since it was scanned.

Always best to make the instruction scan at the same time interval, so I always put PIDs in a periodic task...

Click to expand...

I dont see any timer, the PID instructions are alone in the rung.

Paully's5.0 said:

What are the tuning parameter values?

I had a similar situation years ago, while it 'worked' we needed tighter control, and being in the continuous task the tuning values were really really far-out, I have always wondered how the OEM got it to work in the first place.

After moving it to a periodic task, I got tigher control much easier. Helps to graph the SP, PV and OP valves to see how well the PID loop is actually performing.

Click to expand...

The performance difference of a PID used in a continuous task vs. a periodic task is purely dependent on the application and the necessary response. I would say for most applications its totally fine. With that being said, the PID execution should be triggered by a timer that has a preset value matching 'Loop Update Time' parameter of the PID.

Knowledgebase Article 40236
And in case you don't have TechConnect access, here's a snippet:

"If using a Continuous Task, the PID should be regulated with a Timer bit.

• Match the timer preset with the loop update time of the PID.
  NOTE: If this is not done, then the calculations of the PID will not be consistent. The contribution to the output due to integral and derivative parts of the equation will be proportionately effected in relation to the scan time. This will cause inconsistent behavior from the PID if it is not regulated."

Should I could maybe have one timer by itself on a rung in the pid subroutine and use the dn bit on each pid rung before the instruction?

Yep, that would work fine.

a word of advice ...

just to make it clear ...

if you move the PIDs the way you're talking about, you will be forced to do some MAJOR retuning ... specifically, this will NOT be a simple case of "plug-and-play" ...

you MIGHT (that's "MIGHT") get better response in the long run - but you're DEFINITELY (that's "DEFINITELY") going to have to explain to your boss - and to the equipment operators - why everything was working OK before you started - and why it's taking such a long time to get it back to working OK again now that you've "fixed" it ...

The unit has been running for many years like this

Click to expand...

personally, I wouldn't touch this thing with a ten-foot pole ...

Main program scan time max at 2.836 mS with last around 1.3 mS. Main program max 1555 uS, last 1150 uS. Trying to tune these loops is funky, there are only about 10 PID loops. One of the control valves they have to run in manual because it will not control. One of the speculations of why it will not control is because there is a control valve in front that controls the pressure of the oxygen while the other valve that has to be run in manual controls the flow and they fight each other for control. I was trying to explore options as to how to be able to run them both in automatic.

I agree with Ron... a can of worms

Thomas R/T Chally said:

Main program scan time max at 2.836 mS with last around 1.3 mS. Main program max 1555 uS, last 1150 uS. Trying to tune these loops is funky, there are only about 10 PID loops. One of the control valves they have to run in manual because it will not control. One of the speculations of why it will not control is because there is a control valve in front that controls the pressure of the oxygen while the other valve that has to be run in manual controls the flow and they fight each other for control. I was trying to explore options as to how to be able to run them both in automatic.

Click to expand...

I would think that if your loop time is 200ms, your worst case scan time of almost 3 ms isn't as accurate as a periodic task, but it shouldn't be THAT far off. PIDs can be touchy though, maybe its worse than I think it is.

If you need to change the control scheme to use cascading PIDs or something along those lines, then it might make sense to move those loops to a periodic task, as part of the refactor. If you're making changes and retuning anyway to make it work correctly in full auto, where the code executes should be a small bump in the rest of the changes.

That said, everyone else is right. It IS a can of worms.

my previous advice was based on the understanding that the system had been working "OK" for several years ...

now (based on your latest post) it seems that you really do have a valid reason to "fix" the system ...

here's some advice ... DISCLAIMER: I'm teaching this week so I won't be able to type as much as I'd like – but here's something to get you thinking ...

first of all, I would NOT change anything about the existing PIDs – YET ...

I'd set up an additional PID for each "problem" system – and aim its output signal (CV) at a "dummy" tag location ... put the "new" PIDs in the properly timed routines ... have the "new" PIDs looking at the same (original) input signals as the "old" PIDs ... and feed the "new" PIDs the same setpoints as the "old" PIDs ...

now trend/graph the response of an "old" PID on the same graph as the "new" PID ...

now work on tuning the "new" PID so that its "dummy" output signal closely approximates/tracks the output signal of the "old" PID ...

note that at this point the "new" PID isn't really controlling/affecting the operating system at all ... so far you're just trying to duplicate/match the response of the newly "timed" PID with the older "execute-every-scan" PID ...

then ...

once you have the "new" PID approximating the existing control – then swap the outputs (new and old) and go from there ...

basic idea:

get "close" to what's already working – and then "fine tune" from there ... this approach has been helpful to my customers in the past ...

good luck with your project ...

This is the ordinary PID instruction, not the function-block PIDE instruction.

The ordinary ladder logic PID instruction assumes that the .UPD value in its control block is how often it is being executed, and scales its use of the time-related gains (Integral and Derivative) accordingly.

The ladder-logic PID instruction does NOT measure elapsed time by itself, nor does it adopt the scantime of the Task or Routine it is located in. It relies on the software author to execute it at the correct rate.

In this case, the PID instruction is being executed 50 to 60 times faster than it is configured to be executed. The gains are far, far out of range, and you're wasting processor time because the process variables don't change nearly that fast.

Double-check to be sure that the Subroutine that contains these PIDs is not being executed based on a timer.

I agree that the best approach is to set up another set of PID loops in parallel with the existing ones to experiment with tuning them with realistic gains.