PID Setup in Studio 5000 V29

[matt.smith71]

Hello all,

Last time I did a PID loop was in V20 and that was probably eight years ago. It was a temp control application using a proportional valve.

I'm working on one now that on paper sounds easy. Use a pressure transmitter input (PSI) and adjust a pump speed via 4-20mA analog output to maintain the line pressure. System uses two pumps (one primary and one standby) but the loops should be identical as only ONE pump can be running at a time.

My current thought is to use the pressure feedback as the PV with the VFD Speed as the CV and a manual pressure setpoint. For some reason I don't think that looks quite right.

Any help would be appreciated, or if I'm barking up the wrong tree.

 

[dmargineau]

Welcome to the Forum Matt!

I believe your application should call for only one PID loop with one Process Variable (System Pressure) and one Control Variable (Active Pump Speed).

Install your pressure transmitter after the pumps' outlets convergence and send the PID resulting Pump Speed to the currently active pump; you might need some "tweaking" to make up for the pumps' physical differences, however, there should be only one applied PID logic.

 

[matt.smith71]

Thanks so much for the help. In my example I have the pressure transmitter is downstream of the convergence. Using a single tag for the pump speed is a great idea. Am I on the right track with have the PID setpoint being the pressure setpoint? The input is scaled in the PLC from 0-100PSI in my scaling routine.

 

[dmargineau]

That is the theory...A PID loop will keep the Process Variable at Setpoint value by varying of the Control Variable...

You will have to empirically find out the relation between the pump motor rpm and the resulting outlet pressure for each pump branch, note the eventual differences and accommodate for them when defining the Active Speed Reference and then let the PID do its job; it might take a little longer to tune the loop, however, you should be able to set a common denominator.

 

[Mispeld]

The switching between primary and backup pumps will make this application a bit more complicated. You can get away with the single-PID approach if your two pumps are very similar with respect to process response; if not, you may have to monitor which pump is operating and adjust PID tuning as appropriate.

It is not clear if there are two VFDs involved, and how the pump switching will be handled. This could be important in the final software design, possibly making a two PID approach simpler in the end.

 

[daba]

The switching between primary and backup pumps will make this application a bit more complicated. You can get away with the single-PID approach if your two pumps are very similar with respect to process response; if not, you may have to monitor which pump is operating and adjust PID tuning as appropriate.

It is not clear if there are two VFDs involved, and how the pump switching will be handled. This could be important in the final software design, possibly making a two PID approach simpler in the end.

I slightly disagree with what has been said here.

The PID will drive either pump to maintain the pressure at the setpoint, and it really doesn't matter if the pumps have different characteristics.

They don't need to be "similar" at all, providing each pump can provide the required pressure range, it doesn't matter if one can achieve this at XXXX rpm, and the other at YYYY rpm. What is important is that the PID drives the pumps to provide the setpoint pressure. That is the whole point of PID control, any process factors are dealt with.

 

[AutoMax]

No offense, daba, but I slightly disagree with you. It depends on how critical the response and accuracy of the loop is. I've done redundant systems with alternator logic (each time the system starts with both pump systems healthy a the first pump to start alternates) and it depends on the process. In a wastewater system one loop is adequate, in a paint kitchen I use two.
I suppose you could move different gains into the same PID instruction. Thirteen of one, a bakers dozen of another...

 

[Mispeld]

They don't need to be "similar" at all, providing each pump can provide the required pressure range, it doesn't matter if one can achieve this at XXXX rpm, and the other at YYYY rpm. What is important is that the PID drives the pumps to provide the setpoint pressure. That is the whole point of PID control, any process factors are dealt with.

I would agree in the situation where the loop output (in percent) for pump #1 to deliver xxxx rpm is reasonably similar to that which yields yyyy rpm out of pump #2 (i.e., similar process gains), as well as similar time to reach those typical operating points. "Very similar" was overstating the situation if there is sufficient margin in the PID tuning.

 

[rupej]

Not sure of the application or how critical response time needs to be, but in most cases it should be fine to use one PID with the same gains if the pumps are reasonably similar.

Don't forget to put the PID in a timed task, with the task called exactly as often as the PID update rate. The update rate should be as quick as the processor can reasonably handle for the best control. Something like 1msec would be ideal, but not absolutely necessary.

 

[daba]

Not sure of the application or how critical response time needs to be, but in most cases it should be fine to use one PID with the same gains if the pumps are reasonably similar.

Don't forget to put the PID in a timed task, with the task called exactly as often as the PID update rate. The update rate should be as quick as the processor can reasonably handle for the best control. Something like 1msec would be ideal, but not absolutely necessary.

That would be absurd, considering the analog I/O RTS and RPI would be many many times slower than that.

You'd just be repeatedly calculating with old data, and getting false results.

 

[rupej]

You can set the RPI for the analog input to whatever you want. 1msec or less is no problems for most modern Compact/ControlLogix processors.. There are plenty of pressure transducers with quick enough response to make use of that. I've done it many times.

Also, correct me if I'm wrong, but even if the PID runs faster than the data comes in, it doesn't affect the actual CV output versus a slower update rate that is synchronized with the PV update, so long as derivative is not used, correct? So there should be no downside to having an ultra-fast PID update time.

 

[dmargineau]

You can set the RPI for the analog input to whatever you want. 1msec or less is no problems for most modern Compact/ControlLogix processors.. There are plenty of pressure transducers with quick enough response to make use of that. I've done it many times.

The minimum sample rate (Channel RTS) for the AB 1756 Analog Input modules' channels is 10 ms and the minimum module scan time is 25 ms hence RPIing the Analog module at 1ms is a waste of bandwidth; I have never RPIed any Analog Modules faster than 100 ms but mostly at 250 ms; this is plenty accurate and prompt for most applications; by nature, analog applications are "slow"; if extreme accuracy is needed than a digital rather than analog sensor needs to be used.

Also, correct me if I'm wrong, but even if the PID runs faster than the data comes in, it doesn't affect the actual CV output versus a slower update rate that is synchronized with the PV update, so long as derivative is not used, correct? So there should be no downside to having an ultra-fast PID update time.

If the D is not used that is...You have already reduced the PID efficiency by 33%...
The practical and reasonable approach is to scan the PID routine at the same interval as the module is being polled at thus always using fresh data; also, the Analog channels' RTSs need to be synchronized with the module total scan and the CPU polling RPI.

 

[daba]

Also, correct me if I'm wrong, but even if the PID runs faster than the data comes in, it doesn't affect the actual CV output versus a slower update rate that is synchronized with the PV update, so long as derivative is not used, correct? So there should be no downside to having an ultra-fast PID update time.

Why restrict the use of derivative ? It is crucial in many control loops.

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.

The "Update" interval .UPD, and the instruction execution at that interval, should be matched to the I/O update interval, then the loop is calculating on what the process has done to the PV in that update time, not what the updating scheme has done to the PV. This is fundamental for getting a good tune, and a stable loop.

 

[rupej]

The minimum sample rate (Channel RTS) for the AB 1756 Analog Input modules' channels is 10 ms and the minimum module scan time is 25 ms hence RPIing the Analog module at 1ms is a waste of bandwidth; I have never RPIed any Analog Modules faster than 100 ms but mostly at 250 ms; this is plenty accurate and prompt for most applications; by nature, analog applications are "slow"; if extreme accuracy is needed than a digital rather than analog sensor needs to be used.




If the D is not used that is...You have already reduced the PID efficiency by 33%...
The practical and reasonable approach is to scan the PID routine at the same interval as the module is being polled at thus always using fresh data; also, the Analog channels' RTSs need to be synchronized with the module total scan and the CPU polling RPI.

I guess I was thinking of compactlogix I/O... the quickest module has a 0.3ms RTS and as I recall the RPI can be set to match. For ultra fast pressure control loops (PD pump pushing a thick fluid, for example), I have found incredibly fast update rates on PI loops to work much better than a slow update and a D gain added. The D gain adds less and less value the faster the loop updates.

 

[rupej]

Just looked it up, there are fast analog input modules for ControlLogix too. The previously stated times of 10ms for RTS and 25ms for RPI must be for older hardware.