PID tuning on SLC 5/05

[Robb B]

Originally Posted by drbitboy

From the SLC instruction set manual about PID (here):

Anti-reset windup is a feature that prevents the integral term from becoming
excessive when the output (CO) reaches a limit. When the sum of the PID and
bias terms in the output (CO) reaches the [output] limit, the instruction stops
calculating the integral sum until the output (CO) comes back in range.

So the proposed lower limit ~3900 should be put into the Output Minimum - CVL at Word 12 (N16:12) to ensure the valve opens sooner. This may also change the tuning.

The feed forward/bias in Word 6 is meant for process disturbances, i.e. time-dependent bias.

If I put a minimum value in Word 12, then the valve can never fully close if it needs to, to control pressure. I think the original idea of "bumpless transfer" at some threshold of the setpoint is a better implementation. I'm mostly rambling out loud here, ideas for future tests.

I really appreciate everyone's input, I've certainly learned a lot about PID and process modelling.

[drbitboy]

Originally Posted by Robb B

If I put a minimum value in Word 12, then the valve can never fully close if it needs to, ...

I think you may not understand what is happening here yet: the valve is closed when the PID CV is at or below that minimum value; once the CV is at or below that minimum value, there is no more leakage, so decreasing the CV any more will have no effect on the controlled pressure. Of course the valve stem will not be at 0%, but the valve will most definitely be closed and no fluid will be flowing (this assumes the minimum value entered is not too large; 3900 was at best an estimate courtesy of a calibrated eyeball).

Also, I think that the PID will allow any value, regardless of the CV limits, to be written into the CV Output INT when the PID is in manual model (.AM=1). Even if that is not true, you could always add logic, external to the PID, to put 0 into Words 12 whenever the PID is in Manual Mode, and a positive minimum value (3900 was an estimate/guess!) into Word 12 whenever the PID is in Auto mode (.AM=0).

That said, the approach suggested so far is to use software (the PLC program) to correct for a problem with the physical system. Once we see that this software fix solves the problem, and therefore confirms the source of the problem (the physical valve positioning system), the next step should then be to re-calibrate the positioning system so the valve is closed (has zero leakage) up to a much smaller CV value (It's been a while since I have worled in that end of the business, so I don't know what is typical. 2%? 5-8%?), and then the software PID CV minimum can be returned to 0 poimnentlee.

Another possibility for the source of the problem, instead of mis-calibration, is hysteresis in the valve positioning system.

[drbitboy]

The next time the system is to be pressurized, enter a value, say 3500 or even 2500, into Word 12, manually in RSLogix online mode. The worst that could happen is that the valve would be open and the pressurization would take longer than normal; you can always change it back manually.

But I would bet more than pocket change that what actually will happen is that the pressure will peak much sooner after the PV crosses the SP than you have seen in the past, and the overshoot will be noticeably reduced.

[MaxK]

Originally Posted by Robb B

If I put a minimum value in Word 12, then the valve can never fully close if it needs to, to control pressure. I think the original idea of "bumpless transfer" at some threshold of the setpoint is a better implementation. I'm mostly rambling out loud here, ideas for future tests.

Uhhh. Decompose issue please!

Originally Posted by Robb B

If I put a minimum value in Word 12, then the valve can never fully close if it needs to, to control pressure.

Agree with brbitboy. I'll try to explain the almost the same the other way.

Curves from your post #41 shows nothing happened until control valve opens to ~24% i.e. flow = 0 i.e. DEADBAND. So you have to “cutoff” this useless 24%.

If the customer/management tries to show their "qualifications" (they find your "bug" - an "open" control valve). Because I'm too lazy for the RTFM PIDE instruction, I'll add a rung right below the rung where the PID output is applied to the desired control valve position, something like this:

If PV (pressure) < k*PID_SetPoint then desired control valve position:=0 (k<1)
Or even simpler:
If PV (pressure) < MinPressere then desired control valve position:=0

BUT actually it's necessary to find out what’s wrong with control valve. If anyone is willing fix it, it changes plant gain. i.e. necessitate to re-tune PID.

Originally Posted by Robb B

I think the original idea of "bumpless transfer" at some threshold of the setpoint is a better implementation. I'm mostly rambling out loud here, ideas for future tests.

I can’t find Integral term overloading effect on curves from your post #41 (CV increases almost at the same moment when PV exceeds SP)

I tried to explain at #59 setpoint change response and disturbance rejecting response are not the same (especially in your system).

If I understand you correctly you’ve got PID settings for nice and smote setpoint change response. I 90% sure you can increase PID gain 3-4 times without negative consequences.
Try to multiply PID gain (1,25-1,5) and apply it. See what happened an-1st cycle – I suppose it decreases overpressure without any oscillations. If so – repeat it until "achieve" oscillations or too scared.

[Robb B]

Following up with another trend capture. PID values were 10.0, 0.5, 0.0 and loop update at 0.5 seconds. The pressure built up really slowly this time, so the overshoot was minimized in part due to that. The Control Variable output looks a bit unstable, to my eyes.

[drbitboy]

The PID is fine and doing exactly what it is supposed to do, although maybe 10 is too high for K_c.

The problem is almost certainly downstream of the PID instruction and of the PLC, and instead in the physical valve e.g. stiction, and/or hysteresis and/or backlash in the mechanisms that position the valve stem. Best guess is stiction or play in the linkages, and Word 12 might not fix that because the resulting hysteresis may work both ways.

It's also possible the valve is oversized, but I would chase the others first.

The setpoint ramp at the end is still unnecessary.

[MaxK]

Originally Posted by Robb B

Following up with another trend capture. PID values were 10.0, 0.5, 0.0 and loop update at 0.5 seconds. The pressure built up really slowly this time, so the overshoot was minimized in part due to that. The Control Variable output looks a bit unstable, to my eyes.

We are missing something...

I have few questions:
1. What happened at ~12:43? Before process wasn’t good but acceptable, after – inacceptable. CV achieves 100% then PV changes extremely fast.
2. I suppose CV it is PID instruction output. Have you any data of real outflow (control valve position sensor, outflow flowsensor, even inflow sensor data can help)?
3. Post #1:
“The Control Element is an analog output to a Current to Pressure (I/P) transducer, piloting 3 - 15 psi to a larger valve which modulates the air from the vessel to a vent line. Response time from closed to open is around 8 seconds, if more accurate timing is needed, we can do”

- Is the control valve Response time from closed to open is around 8 seconds? That's for sure?
- Is there two valves? Small valve controlling control valve?

4. Please recall very accurately what happened (some valves opened/closed, pump performance increased/decreased etc.) during the cycle shown.

Try to understand the "simple" idea: you can't tune a PID controller, you can only tune an entire closed system (closed loop). Sounds simple, but not so easy to really understand. Imagine an open loop, you apply some kind of influence, you get some kind of response, and the influence “goes away”. In a closed loop, ANY influence "continues" in the system.

To set up a system (closed loop), you must know (understand) how (when, why, why) each element of the system “works” (pump, valves, pipes, etc. - everything that includes a closed loop).

... I assuming something not such simple with control valve(s) ...

[MaxK]

Originally Posted by Robb B

Following up with another trend capture. PID values were 10.0, 0.5, 0.0 and loop update at 0.5 seconds. The pressure built up really slowly this time, so the overshoot was minimized in part due to that. The Control Variable output looks a bit unstable, to my eyes.

Can’t you attach time+PV values at txt/xls file or show more scaled PV curve? I'll try to calculate process input (control valve position).

[Peter Nachtwey]

Originally Posted by MaxK

Can’t you attach time+PV values at txt/xls file or show more scaled PV curve? I'll try to calculate process input (control valve position).

A trend with the valve position and control output as a function of time is required. Having the actual pressure would be nice too.

[Robb B]

Originally Posted by Peter Nachtwey

A trend with the valve position and control output as a function of time is required. Having the actual pressure would be nice too.

valve position has no feedback so no measurable position, only what is indicated by control variable output (which is scaled 4-20 to the current/pressure transducer which pilots 3-15 psi to the valve.

psi PV is actual pressure as measured by transmitter.

[Robb B]

Originally Posted by MaxK

Can’t you attach time+PV values at txt/xls file or show more scaled PV curve? I'll try to calculate process input (control valve position).

I'm not sure how to do this in txt/excel format, I have logix 500 for trending. I can do another trend with increased sample rate if that would help.

[Robb B]

Originally Posted by MaxK

We are missing something...

I have few questions:
1. What happened at ~12:43? Before process wasn’t good but acceptable, after – inacceptable. CV achieves 100% then PV changes extremely fast.
2. I suppose CV it is PID instruction output. Have you any data of real outflow (control valve position sensor, outflow flowsensor, even inflow sensor data can help)?
3. Post #1:
“The Control Element is an analog output to a Current to Pressure (I/P) transducer, piloting 3 - 15 psi to a larger valve which modulates the air from the vessel to a vent line. Response time from closed to open is around 8 seconds, if more accurate timing is needed, we can do”

- Is the control valve Response time from closed to open is around 8 seconds? That's for sure?
- Is there two valves? Small valve controlling control valve?

4. Please recall very accurately what happened (some valves opened/closed, pump performance increased/decreased etc.) during the cycle shown.

Try to understand the "simple" idea: you can't tune a PID controller, you can only tune an entire closed system (closed loop). Sounds simple, but not so easy to really understand. Imagine an open loop, you apply some kind of influence, you get some kind of response, and the influence “goes away”. In a closed loop, ANY influence "continues" in the system.

To set up a system (closed loop), you must know (understand) how (when, why, why) each element of the system “works” (pump, valves, pipes, etc. - everything that includes a closed loop).

... I assuming something not such simple with control valve(s) ...

1. Myself and the operator don't know what happened at 12:43, we have never seen something like that before. I could guess at maybe an air pocket or something. We are measuring the air pressure created by the oil in a small area of piping at the top of the vessel, so all sorts of things could happen.

2. No other data for the flow through the pipe. I can chart the volume of oil going into the wood over time, but it's relatively small (about 2200 gallons over 12-24 hours) and difficult to measure precisely. There's only a radar level transmitter for that measurement.

3. I will try to capture or measure actual valve action from closed to open while empty and with flow. This will take some time to capture. There is a transducer which pilots air to the larger valve, so I guess technically there is two valves. The transducer action is quite fast compared to the main valve, so I suppose this introduces some dead time.

Again, I thank everyone for their contributions, I'm learning some really cool things! I haven't had the courage to try working with this setup before now, but I feel better informed now!

[Robb B]

Originally Posted by drbitboy

The PID is fine and doing exactly what it is supposed to do, although maybe 10 is too high for K_c.

The problem is almost certainly downstream of the PID instruction and of the PLC, and instead in the physical valve e.g. stiction, and/or hysteresis and/or backlash in the mechanisms that position the valve stem. Best guess is stiction or play in the linkages, and Word 12 might not fix that because the resulting hysteresis may work both ways.

It's also possible the valve is oversized, but I would chase the others first.

The setpoint ramp at the end is still unnecessary.

The setpoint ramping is unnecessary but it's part of their required process (safety) to bleed the pressure off in the vessel in a controlled manner. I would be curious to find out if there is some sort of backlash or something in the valve. I think the pressure of the flow through the valve will create some stiction, but if anything I would expect it to cause the valve to open faster than it can close, due to the flow/pressure.

[drbitboy]

Is it safe to put someone at the valve with a tape measure or ruler or yardstick? You can be watching the trend, so at the time when the CV reaches a peak or valley, and starts one of it subsequent descents or climbs, respectively, the person at the valve can tell you how long it takes after the time of the peak or valley that the valve starts moving.

I estimate there is backlash of at least 5-10% in the valve positioning system. Look at the data:

When the pressure is rising and above setpoint, the CV will be increasing as the PID tries to compensate, e.g. just after at 12:34:02, the actual valve position is some offset in percentage behind the CV. As the valve actually starts opening and the pressure eventually starts dropping, the CV peaks with the valve at some position, call it VPhi. The CV then drops because the [rate of PV (or E) drop] times [K_c] times [update period], i.e. the proportional change per PID update, is more negative than the [E] times [K_c] divided by [T_i], i.e. the integral accumulation, is positive, per PID update. However, as the CV initially drops from that peak, the valve position is not changing, and remains at VPhi. This is obvious in that we see the PV dropping at an essentially constant rate for around 15s or so from its peak while CV is dropping. If the decreasing CV were changing the actual valve position during those 15s, the rate of PV change would decrease, but it does not.

After those 15s, the accumulated drop in CV takes out the backlash and starts actually moving (closing) the valve again i.e. reducing the actual valve position from VPhi. And at that point we the PV rate of change decrease. But because of that backlash, the CV overshoots.

This happens again and again, as the actual valve position lags the CV after every CV peak and valley. The correct fix is to eliminate the backlash.

A possible software solution would be to add or subtract some fraction of the backlash as the Feedforward/Bias term of the PID: positive bias when the CV is increasing; negative bias when the CV is decreasing; zero bias when the CV is level.

Perhaps a deadband* model for the CV would work and be not too complicated to implement in a handful of rungs:

• Append the CV to a FIFO at every PID update i.e. the FIFO trigger would be the PID DN, bit 13 of Word 0, one-shot is one
• Have a pair of FALs that find the maximum and minimum values in the CV
• If the current CV is more than some percentage (2?) above the minimum, and the current PID feedforward/bias is not positive [LEQ PID_Word_6 0], then assign a positive value to the feedforward/bias of 5-10% of the range (e.g. +1638 for +10%).
• If the current CV is less than some percentage (2%?) below the minimum, and the current PID feedforward/bias is not negative [GEQ PID_Word_6 0], then assign a negative value to the feedforward/bias of 5-10% of the range (e.g. -1638 for -10%).
• If the current CV is neither of those, then assign a value of 0 to the feedforward/bias.

Hmm, one problem with that algorithm is that the feedforward/bias will affect the FIFO.

* N.B. this has nothing to do with the deadband parameter of the PID instructions.

[drbitboy]

I don't know if this approach would work in the field, but I created a model that takes a CV output as the input, and calculates what the actual valve position would be assuming a fixed amount of backlash in either direction. The code is shown in the first image below.

The second image uses a PID to calculate a bias to be added to a target CV, and the sum of that target CV and the bias is passed to the backlash model to predict a valve position, and finally the error between the predicted valve position and the original target CV is used to drive a PID to calculate the bias.

The third image shows a plot of the result. The target CV is the darker blue trend, which is mostly hidden behind the green modeled valve position (VPmodel), and the [CVplus = CV + bias], which is the input to the backlash model and is what would actually be sent to the valve, is the lighter blue trend; all of those are scaled 0 to 16383. The brown and pink plots are the error and the bias (PID output), and are scaled between -2000 and +2000

I used CCW because it has a PID and is easy to make trends, but the same approach could be implemented in the SLC. Whether it would work to drive the actual valve position to the pressure control PID's output CV, when that CV is not as well-mannered as the synthetic sine wave in this example, is another matter entirely.

backlash_model.png

valve_backlash_main.png

backlash_trend.png