Correcting PID tuning values for incorrect loop update time

Hi all, splitting out from this thread because it's a somewhat different question to the original.

I have to migrate some code from a Micrologix 1100 to a 5380 Compact Logix. It includes a PID loop. I was hoping not to have to re-tune the loop, because many engineers have spent a lot of time working out the optimal values for this loop, and I'd rather not reinvent the wheel. I figured initially that as long as I configure the loop the same and put the same tuning values in, I should get more or less the same response regardless of platform.

However, the programmers of the ML1100 did not set up the loop update of the PID correctly. They set it to 30ms, but then executed it every scan in the main routine. So the PID loop thinks the update time is 30ms, but the actual update time is whatever the scan time of the PLC happens to be.

I'll be onsite tomorrow and will check the scan time of the PLC. If I find that it is, e.g. 10ms, is there a rule-of-thumb or guesstimate that I could apply to my gain parameters to compensate for the fact that the PID thinks it's updating at one-third the rate it actually is?

ASF
Hi, are you using this PID in the new Compact logix on an unconditioned rung with a free-running update timer? Using an XIO on the .dn to reset the timer? If so, and this is what I've done with all the PID's I configured, the update time has to equal the update time preset in the timer. Meaning in the PID configuration tab. Hope this helps. If you're using a periodic task, I've never used those, so I can't be of much assistance there.

Hey ASF. So I'm assuming you'll be using the dependent equation on the 5069, since the ML1100 was dependent?

If so, P should be P, regardless of the change in update time. If the PID instruction is being called 3 times as often as it was configured for (per your 10ms vs 30ms example), then I believe you will need to divide the i and d times by 3 numerically. In other words, increasing their effective gain by a factor of 3.

Also, just as a CYA, you could test this in the ML by making two new PIDs, one configured incorrectly, and one right. Set the PV and SP to some bogus number and start them both at the same time. See if the CV is identical as they ramp up.

When migrating from a Micro 1100 to compact logic thing change with the PID
My guess is that your PID control runs to either full on 100% or full off 0%
Move the PID control to a periodic task update time set to 100ms
the PID control is updating the outputs faster then the hardware can respond
Basically you need to slow it sown to allow it to work

Thanks rupej. Yes, I'll be using the dependent equation (Ron Beaufort gave me that tip in a previous post) and it'll be in a period task executed at 30ms.

I'm confident that you're right about P being P regardless of loop update time. It's purely a case of "multiply error right at this instant by P". So that's easy enough.


The current system has no derivative gain, so I don't have to worry about that, which just leaves integral.

But I'm not sure about the I gain on a dependent loop - I'm not sure whether it can really be as simple as divide by three.

Let's say I had independent gains. I set up a system with a 10% error and give it an integral gain of 0.2 minutes per repeat. On a correctly configured loop the I component would introduce a 10% change in the output in 0.2 minutes, or 12 seconds. However, if the loop was actually executing three times faster than it realised, it would introduce a 10% change in only 4 seconds. To achieve the 10% change in 4 seconds with a correctly configured loop, we would change the I gain to 0.0667 minutes per repeat. This would achieve a 10% change in the same 4 seconds that the incorrectly configured loop achieves it. So, yes, divide my I gain by 3 and I'm away.

But how does that change if I'm using dependent gains? Do I need to do something like:
Incorrect I Gain * P Gain / 3 / P Gain = Correct I Gain ?

The recommended update time for a PID in Logix processor is 100ms 30 mat be to short

I've just got my colleague to hook up a ML1400 on the test bench and have me teamviewer in so I could run some tests. The tl;dr is that rupej is exactly correct.

I set up a PID instruction in an STI task and ran a series of tests. For each test, the loop update time was 30ms, integral gain was 1.0 (minutes per repeat), and I introduced a 10% error.

Test 1: STI set to 30ms, Proportional Gain 1.0
When the 10% error was introduced, the P gain immediately gave a 10% change in output. The integral gain added another 10% to the output in exactly one minute. All as expected for a properly configured PID loop.

Test 2: STI set to 15ms (loop update still 30ms), Proportional Gain 1.0
When the 10% error was introduced, the P gain immediately gave a 10% change in output. The integral gain added another 10% to the output in exactly 30 seconds. This is what we discussed would happen. Because the scan rate is half of what it should be, I would have to double the integral time to make it respond the same as the correctly configured loop.

Test 3: STI set to 30ms, Proportional Gain 0.5
When the 10% error was introduced, the P gain immediately gave a 5% change in output. The integral gain added another 5% to the output in exactly one minute. All as expected for a properly configured dependent PID loop - I presume if I could test independent gains, the P gain would have given 5% immediately and the I gain would have given 10% in one minute.

Test 4: STI set to 15ms (loop update still 30ms), Proportional Gain 0.5
When the 10% error was introduced, the P gain immediately gave a 5% change in output. The integral gain added another 5% to the output in exactly 30 seconds. Again, because the scan rate is half of what it should be, I would have to double the integral time to make it respond the same as the correctly configured loop.

So, the upshot of all this is that yes, I should be able to just reduce my integral gain by the same factor that the scan time is incorrect, and it should act the same.

GaryS said:

The recommended update time for a PID in Logix processor is 100ms 30 mat be to short

Click to expand...

This is a tension control loop. A 100ms response time will not be fast enough to control the loop.

I'm inclined to think that if the Micrologix 1100 (which is by now almost 15 years old) can handle the 30ms update time, then a brand new 5380 Compact Logix should manage it okay

I will try to explain it the way I understand it.
You keep running the test with the same processor with the same data and wonder why the results are the same. Try running it in a Logix processor
First the scan times between the ML1400 and a Logix processor are completely different, the Logix processors are about 1000 time faster.
With the ML1400 the PID control updates when the rung is true and the update time times out
The Logix processor calculates the PID control every time the scanned rung is true. That would be about 500,000 times a sec. I have seen scan time on Logix processors in 20 Pico Sec range or faster on a medium sized program.
On each calculation it updates the data in the PID that would include the set point feedback error. It expects to see the feedback to change with the change in pid output but there is just no hardware out there that can change fast enough to make the feedback change at the rate necessary so on the next update the error increases and the calculation will increase or decrease the output according to the calculated error so it is easy to see how in just 1 second the pid output is maxed out.
That’s why the 100ms periodic task on the Logix
I spent hours chasing my tail on this myself before I found out about the difference, after I made the change it worked perfectly. On that job it had about 5 or 6 PID controls none would work until I moved them into the periodic 100ms task
My advice would be to try it in a Logix processor
I think there is a tech note on this out there

if you can't control a tension loop at 100ms update time then you never will the hardware just doesn't respond that fast

keep a careful eye on the scaling too ... if the original setup had the "timing/triggering" wrong - then there's a chance that the input and output scaling were also incorrect ...

good luck with it - and let us know how it all turns out ...

GaryS said:

I have seen scan time on Logix processors in 20 Pico Sec range or faster on a medium sized program.

Click to expand...

This will be with those new 50Ghz processors with enough multicores to run your entire code in one CPU clock cycle.

GaryS said:

if you can't control a tension loop at 100ms update time then you never will the hardware just doesn't respond that fast

Click to expand...

I would have to look at some data sheets but I am sure you can go faster than 100ms. Yeah, if your process has a 5minute lag time you will run into rounding issues, but it is all proportional.

Gary, I think the key with the situation you are referring to is to make sure that the PID loop update matches how often the instruction is scanned. Putting it in a 100ms periodic task worked for you because you were no longer scanning it continuously. That's basically the same issue ASF had encountered in the MicroLogix.

I've been successful at running very fast PIDs with updates at 1ms. I'm sure you can go faster than that if necessary. As long as your input can update that fast and the RPI on the analog module is at least that fast, there should be no issues.

Hi Gary,


Yes, I understand the difference in scan time between the ML1100 and the CLX, and the need to set them up in periodic tasks. As always I'll be putting the PID instruction in a periodic task. Usually I set up my PID tasks at one second, or occasionally 100ms for faster loops like flow. I've not read the official recommendation from AB on PID task frequencies, but 100ms makes sense because by default that's how fast your analog I/O updates. For 99.9% of applications 100ms is plenty fast enough, and if you need it to go any faster it does get more complicated because you have to ensure your analog I/O is getting you updated information fast enough for the increased PID scan to have meaningful data to work with. It's definitely doable, just requires a little bit more configuration than just "make the periodic task faster".

In any case, the configuration at the CLX end I'm generally OK with. The information I was trying to find here was related to how to correct tuning values in a ML1100, to account for the fact that the PID instruction has been incorrectly configured. After my tests above, I think I've got it worked out OK. I'll give it a try later today and see how I get on.

Ron Beaufort said:

keep a careful eye on the scaling too ... if the original setup had the "timing/triggering" wrong - then there's a chance that the input and output scaling were also incorrect ...

good luck with it - and let us know how it all turns out ...

Click to expand...

Thanks Ron. Looks like the scaling is all correct - small mercies!