PID Setup in Studio 5000 V29

[rupej]

If you execute the PID instruction n times faster than the feedback data is refreshed, then the PID will think nothing has happened since it was last scanned, and will make no adjustments to CV. Then along comes what it sees as a large change in PV in a short time, and any D term will kick in with a vengeance. The following n scans will again see no change in PV until the next "new PV". This will make the loop much harder to tune, and will nearly always result in poor control.

I just wanted to respond to this because I don't believe it is correct and don't want it to confuse the OP or a future reader.

Even if the PV is the same for a few updates on an extremely quick PID loop, the PID controller WILL continue to make changes to the CV, that is what the integral gain does. The D term will not "kick in with a vengence," in fact, it will do even less than on a slow update loop because a fast update rate will result in a smaller change in PV per scan.

I have done fast update PID loops dozens of times and the benefit is that the controller is able to make a response much quicker to an upset. It does not "nearly always result in poor control", it actually works better.

I think the old line of "set your update rate to 100ms - 500ms" or whatever is a throwback from when processors were much slower, and I suspect the folks who argue that have never knowingly tried using a fast update time.

Analog signals are not necessarily "slow by nature." There is a reason that Rockwell makes fast analog I/O modules for Compact/ControlLogix. As another data point, the internal PID loop in PowerFlex 523/525 drives (and possibly others) updates at an unchangeable 1ms interval. Why would it be so fast if that "nearly always results in poor control"?

 

[dmargineau]

I think the old line of "set your update rate to 100ms - 500ms" or whatever is a throwback from when processors were much slower, and I suspect the folks who argue that have never knowingly tried using a fast update time.

I, on the contrary, suspect that the folks claiming they are running PIDs without derivative components but integrating stale data and RPIing analog modules at single digit milliseconds do not quite understand the analog circuitry physics and the PID concept generally...

 

[rupej]

"If someone's ideas challenge my understanding then they must be wrong."

The data is not stale if the circuitry is keeping up. As mentioned, transmitters and I/O modules can easily update at 1ms or faster.

My comment about running the loop even faster than the new data comes in was that it is no worse off than exactly keeping pace with the data change, and slightly better since it can respond instantly as soon as the data does change. An integral action working on the same data for 5 updates over a period of 5ms is exactly the same response as the integral action of a single update every 5ms.

How stale is the data if you wait 250ms to even check it? How much has changed since you checked it last? If you've ever had to tune very fast pressure loops, you would know that a lot can change in a quarter of a second. It is better to know what is happening as soon as possible than to wait around for some arbitrary amount of time before making a response.

 

[rupej]

Also, there is nothing in the program that automatically synchronizes the I/O update to the PID update. So if you set the RPI to 250msec and the PID update to match, you may be working with data that is current, or it could be 249.999 msec old. That would be stale data. Yet this is typically taught as best practice presumably because it works "well enough" for most situations.