How Fast Does Valve Position Communication Need to Be?

I got an excellent question during Deminar #3. An attendee asked how fast does the readback of actual valve position need to be as a secondary variable from a smart positioner. I said it depended on the speed of the valve. For flow loops, I thought once per second would be fast enough. However, since the communication of the actual valve position is not synchronized with PID module execution, there needs to be more than one communication per module execution time. Also, for very fast valves, the valve response time could be much less than the module execution time. The dynamic reset limit needs to know the valve is actually moving or it will slow down the change in controller output. For wireless communication of position measurement, exception reporting could be used where the deadband for updating the position readback is the resolution limit of the valve.

A guideline for the conventional PID could be:

When the controller output changes by an amount greater than resolution of the valve, the communication of the valve position for the dynamic reset limit of a conventional PID should be less than ½ the module execution time and less than ¼ the valve response time.

For an enhanced PID as described in Deminar 1, it is possible that valve position only needs to be communicated when a new measurement value is communicated.

The response time per the ISA-75.25.01-2000 (R2009) standard Test Procedure for Control Valve Response Measurement from Step Inputs is the time the valve takes to reach 86% of the final stroke. As noted in slides 12 & 13 in Deminar 3, the response time for small signals and small actuators is a second order exponential response (response time is approximately twice the sum of the time constants) whereas the response time for large signal and large actuators is a ramp (e.g. response time is 86% of the step change in signal (%) divided by the slewing rate (%/sec)). For valves with hydraulic or digital actuators or small valves with a negligible deadtime from backlash and stiction and with a high sensitivity actuator and positioner (e.g. sliding stem valve diaphragm actuator and digital positioner), the response time could be less than a second. For extremely large valves with excessive deadtime from backlash and stiction and with a low sensitivity actuator and positioner (e.g. piping valve with scotch yoke actuator and pinned shaft connections) the response time could be more than 100 seconds. Thus, we have the ironic situation, where if we have a poor valve choice, the resolution and update rate of actuator position communication can be decreased and the filtering of noise can be decreased to keep fluctuations in controller output from measurement noise less than valve dead-band and resolution. If you don’t do small step tests or have no communication of actual valve position, the poor loop performance from a piping valve posing as a control valve may be attributed to disturbances or noise.

The accuracy of the valve position communicated is not as important as precision since it is the change in valve position rather than the value of valve position that is important. The bias and span errors in valve position are corrected by feedback control of the process loop. Since even the best valves with pneumatic actuators do not respond to changes in signal less than 0.1%, the greater resolution of digital values of valve position communication is unnecessary. Consequently, to get faster communication for fast valves and small signal changes, analog signals of valve position should be used for the dynamic reset limit even though they may not be as accurate as digital signals.

The precision of the valve position communication should be better than resolution limit of the control valve (e.g. 0.1% for sliding stem valves with diaphragm actuators and digital positioners).

All of what I have presupposed here needs to be tested and investigated. There is no shortage of interesting scenarios to investigate via dynamic simulation.