Using one PID Instruction for several loops.

[daba]

.....

What is the advantage of 1 loop per sub?

You can kill one if you have to....

 

[widelto]

In my case I use FB (PIDE), and it´s easier to use a sub for each loop, if you use ladder i see no problem.

 

[rdrast]

On lines where I have 20 or more temperature PID's, I generally break them down so I am only calling two or three of them each pass through the periodic task.

I generally have the PID/PIDE update time set for one second, and run that periodic task every 60 or 100 ms.

 

[daba]

On lines where I have 20 or more temperature PID's, I generally break them down so I am only calling two or three of them each pass through the periodic task.

I generally have the PID/PIDE update time set for one second, and run that periodic task every 60 or 100 ms.

The update time set into the PID should be equal to the actual period at which the instruction gets executed for best results.

After all, the PID is an instruction which does calculations based on time, and it needs to know the interval since it did its last set of calculations to be able to assimilate the Integral and Derivative terms.

I put PIDs on a "cycle-count" also, to spread the PID instructions' executions over several cycles, but I always engineer it so that each PID gets executed at the time interval I put into the PIDs .Update parameter.

e.g. a "cycle" of 5, in a periodic task set at 100mS, means that each PID gets executed at 500mS intervals, that goes into each PIDs .Update parameter.

 

[rdrast]

Yah, I guess I should have made that clear.
Normally, what I do, is define a real tag, and call it "task_PID_Update", and set that to a convenient value, example 1 second as a default. I pass that to each individual PID/E instruction, then decide how many ways I want to break them down.

Finally, in the periodic task scheduler, I take the actual task rate (from a GSV), multiply it by the number of 'phases' I want to execute the PID's in, and then update the task_PID_Update value so all the loops have a proper value.

I guess describing it is complicated, but it makes sure that
A) There is a default value for the first run,
B) The tuning remains consistent even if I add or subtract scan phases for the loops,
C) The tuning remains consistent even if I change the periodic task cycle time.