PID Loop Update Match Execution Time

Today I upgraded an L55 processor with an L82, which ended up being the 2nd unsuccessful attempt but thats a different story. After starting the process back up we noticed a few of the pumps that try to maintain a set pressure were surging up and down really fast. I traced the control back to a unconditioned PID command that was being executed every scan. Luckily I had ran into this a while back and remembered that the loop update time had to match the PID execution time and after a little programming got that running correctly.

Afterwards I started digging into it a little more just to find out why that actually makes such a big difference but I couldn't really find a detailed explanation on the Rockwell knowledge-base. I was hoping someone from here could explain a little better. If you have links to other posts i've missed, thats fine too.

Thanks

The explanation below is probably wrong in every detail, but I think it paints the right picture. Admittedly, Logix isn't my primary platform, so someone with more knowledge than me can correct the specifics, if needed.

When you're tuning the PID, it's essentially saying "add X ticks to the value each Y milliseconds". It adjusts the X based on a ratio of each of the PID factors. It takes the Y of the ratio from the time you give it. If that doesn't match how often the block is actually called, your gains aren't what they used to be.

As an example, say you tell the block that it will be running every 100ms, and based on the gains, it thinks it needs to add 5. It does that this scan, and then 100ms later, maybe it adds half that, based on the new PID calculation.

However, if you tell it that it is running at 100ms, but it is really running at 10ms, suddenly it is adding 5 this scan, and 5 the scan after that, and 5 the scan after that, and then suddenly you've added 50 over the 100ms instead of 5. It essentially scaled up your gains by 10.

I've generally seen PIDs run out of interrupts at a defined cycle time, like every 100ms, (I can't recall what that kind of task is called: Cyclic? Timed?), instead of the whenever it gets around to it of the normal task. This way they are pretty much independent of the rest of the CPU processing, even when moving to faster processors.

This is easy.
You need to look at the formula for a PID.
error=SP-PV
CO=CO(n-1)+ Ki*T*error+Kp*error+(Kd/T)*(error-error(n-1))
You can see that T, the sample interval, plays a significant part in how the integrator and derivative gains act.
If T, the sample interval, doesn't match the real sample rate then Ki*T will be wrong.
In your case the PLC is MUCH MUCH faster than the old one so effectively the Ki was increased by (old sample rate/new sample rate). In the same way the effective derivative gain was reduced by the same amount.

What you described makes sense since the new sample, rate vs the old one, would accumulate error or control output faster.

Peter Nachtwey said:

This is easy.
You need to look at the formula for a PID.
error=SP-PV
CO=CO(n-1)+ Ki*T*error+Kp*error+(Kd/T)*(error-error(n-1))
You can see that T, the sample interval, plays a significant part in how the integrator and derivative gains act.
If T, the sample interval, doesn't match the real sample rate then Ki*T will be wrong.
In your case the PLC is MUCH MUCH faster than the old one so effectively the Ki was increased by (old sample rate/new sample rate). In the same way the effective derivative gain was reduced by the same amount.

What you described makes sense since the new sample, rate vs the old one, would accumulate error or control output faster.

Click to expand...

I ended up having to put the old processor back in due to other communication related issues but I'm going to attempt the replacement again next time I get a chance. Since the sample time affects the calculation, will just adding a timer that matches the loop update time still affect the gain settings? Since the existing program has the PID in an unconditional rung in a continuous routine, would it be better to find the existing routines scan time then match a timer and the loop update to that value? I know it will be hard to get that perfect but it seems like it would keep the gains pretty close to the existing values and give a decent starting point.

Is the PID in the main contentious routine or in a periodic task?

alan_505 said:

Is the PID in the main contentious routine or in a periodic task?

Click to expand...

mjp123gp stated clearly that it was in the continuous task...

My recommendation would be to put the PID instruction (just the PID instruction, none of the other logic) in a routine in a new Periodic Task.
Whatever the task period is set to, write that time into the loop's .UPD parameter, so that the maths knows the time period of the instructions' execution. Fit it and forget it.

You can use a timer to execute the PID block, but it will not be as accurate as the periodic task, because the timer will always "overshoot" the the set time, because it is serviced during the scan. The scan time is not consistent, so you will always get some "jitter" in the PID execution period.
Whichever way you go, timer or periodic task, you will likely have to re-tune the loop.

Even periodic tasks or putting the PID in interrupts will not avoid jitter. During the house keeping the interrupts are turned off.
It is a shame that the people that write these PIDs are novices. I would use the hardware clock to measure the time between samples or better yet the sampling devices themselves should have a time stamp down to the microsecond. Then the interval between samples is known and can be used to automatically update the time between samples so NO ONE HAS TO WORRY ABOUT IT AGAIN!!!!

Out of curiosity, how are you "upgrading". Are you going into controller properties and changing the controller to an L82 or are you exporting to an L5X file and re-importing to a new project?

Peter Nachtwey said:

Then the interval between samples is known and can be used to automatically update the time between samples so NO ONE HAS TO WORRY ABOUT IT AGAIN!!!!

Click to expand...

Top of my head if you use the PIDE instruction in a continuous task it will calculate the update time, BUT it drops the decimal off (I think - I don't remember it rounding).... So close Rockwell...

The PID instruction follows the PLC5 model of needing to be told (presumably for program conversion compatibility)

Peter Nachtwey said:

Even periodic tasks or putting the PID in interrupts will not avoid jitter. During the house keeping the interrupts are turned off.
It is a shame that the people that write these PIDs are novices. I would use the hardware clock to measure the time between samples or better yet the sampling devices themselves should have a time stamp down to the microsecond. Then the interval between samples is known and can be used to automatically update the time between samples so NO ONE HAS TO WORRY ABOUT IT AGAIN!!!!

Click to expand...

I think any jitter that may be caused by System Overhead will be inconsequential compared to the lumpiness of the analog input and output modules' Real-Time Sample rates (A/D and D/A conversion rates). You could be calculating with feedback signals that are up to 100mS old, so the few milliseconds that might delay a periodic task does not create a problem. And, once initiated, a periodic task cannot be interrupted by System Overhead, so keeping the amount of code in the periodic task is advisable.

Yes, you could use the time-stamp from the analog card to calculate the effective update time and put that into the PID .UPD register, but I have never had the need to do so in over 20 years of configuring and tuning 100's of PIDs.

On the CompactLogix, you can set your Periodic Task to have a higher priority than I/O processing and System Overhead, so the periodic task execution rate would become consistent.

I only have ControlLogix to play with, I will run a test to see what effect System Overhead has on the accuracy of periodic task rate.

@Raffles, I haven't used the PIDE.
@daba, I agree that the sample jitter usually isn't significant except when trying to computer derivative gains and rates.

Aren't input modules 16 bits yet?

The argument you make about old and quantized data is the one we make to people trying to do hydraulic servo control. Many do not listen and wastes months before admitting they should have listened to us.

Running your tests should be an eye opener. For a challenge, change the SP as function of a sine wave. Try increasing the frequency. Phase lag is a killer.

Peter - the PIDE instruction is a meaty beast - full of stuff that in my opinion would be better off being done outside of the function block and just let that run a loop. It use a velocity form of the equation working on change in error rather than error directly. I have a vague memory they did this because that is what most DCS systems use (apparently).

The PIDE and all the other "advanced" process control instructions (internal model control, Modular Multivariable Control etc.) were wrote by a third party. The fact that you can't use the instructions in ladder is actually way of licensing the autotune (part of the agreement apparently with said third party) - thats why you have to pay more to program in ST or FBD

I prefer the 'velocity' form over the regular form. I can change gains on-the-fly without the fear of getting huge jumps in the output. Also, the integrator doesn't wind up at all or as badly as the regular form.

BTW, I hate the term 'velocity' form. It has nothing to do with velocity. I prefer to call it the incremental form because it integrates increments of output. This was discussed a long time ago on sci.engr.control before it got overrun by spammers.

PIDs should be lean and mean. The incremental form is very lean even if you add feed forwards and limits.

The velocity or incremental form is very convenient for applying rate of change limits and absolute limits. saves so much hassle avoiding various ways to wind up and has let me delete a lot of logic to reset the integrator in different scenarios

kekrahulik said:

Out of curiosity, how are you "upgrading". Are you going into controller properties and changing the controller to an L82 or are you exporting to an L5X file and re-importing to a new project?

Click to expand...

I changed it in the controller properties.