Emerson Exchange 365

In reply to James Beall:

I couldn't paste the screen shot of BOL. The title of the section is "Control Selector function block application information".

In reply to James Beall:

James,
thanks for the reply, I tried to send an email to you via direct return, but not sure if it gets through.
Yes, we have implemented the scheme as per the suggested block diagram from the DeltaV manual. It doesnt do what the nameplate says it should, i.e. the non selected controllers dont track, they wind up. Is there a setting within the PID controllers that must be changed to make the tracking work?
Also, does the scheme work regardless of whether the controllers are in Auto or manual, i.e. will the non-selected controllers in auto track a selected controller that is in manual, i.e. if the operator is manually closing in the valve via one controller faceplate.

Jeff Richards

In reply to jeff richards:

Richard,
No other setting is needed, it should work fine. Make sure you are using "Control Selector" block, not an "Input selector" block. Be sure to select the proper action (low or high select) on the Control Selector.

Yes, if you put one (or both) controllers in Manual, and move its output in the direction to be selected (Low or High) it will go to the block downstream of the control selector.

My email address is james.beall@emerson.com

In reply to James Beall:

Jeff,
One thing to note is the tracking through the first order "reset filter" which can cause the action to look "strange" if are not aware of it. Assume the non-selected PID has a gain of 2 and an error of 5%. It's output will be offset (below for a high select application, above for low select application) from the selected PID Out by the amount of (2 * 5%) = 10%. So, if the selected OUT is 40%, for a low select application the non-selected PID Out will be 40%+10%=50%. Suppose the selected PID Out steps to 25%, the non-selected PID Out will move from 50% to 55% in a first order exponential pattern with a time constant equal to the Rest time of the non selected PID. Thus, at one Reset time, the non selected PID Out will be ~53.2% and will be nearly to 55% in 4*Reset time. Thus, you can see that if the Reset time of the non selected PID is more than 2-3 seconds, it will take a while for the non-selected PID Out to get to its final value when the selected loop Out moves. This may cause the illusion of Integral Windup but if connected correctly, it is not Integral Windup.

James

In reply to jeff richards:

Jeff, The limit controllers output isn't winding up. Wind up is the result of integral or reset action on the output. The Output of the PID not in control is offset by its GAIN *Error. As the PV approaches the limit set point, the Error goes to 0 and the controller's output, which is tracking the Selector output, will converge. If the PV continues to move past the limit, that controller takes over as it drives its output to be the selected control signal. This is normal behavior of an Override control strategy.

It can be disconcerting to Operators who see the not-selected controller's output be different than the control signal, thinking that if it switches over there will be a huge bump in the valve position. I've seen the override strategy replaced by a user configuration that used Output Tracking because they did not want to see the not-selected control loop Output moving around as you have observed. That brings in a whole new set of problems managing the transition between loops.

Some engineers treat the limit PID as a standard PID module with its own control module. I think of it as part of the primary loop, and embed the PID block into the same module with the control selector and the primary PID. One likely wants to see an indication of the override PV so I would have an AI for that. Then the only module the operator deals with is the primary loop, which is either in Flow control or is in override control. The operator can always act on the Output of this loop directly. If the override PID process time constant is also fast, having the PID loops and Control Select block in different modules will add execution dead time that may limit loop performance. If the Override Loop is a slower loop, the impact of separate modules may not be of concern.

Override is a very stable and functional strategy. It is also referred to as Constraint control. If you look at your application, it could be a very good candidate for an MPC with a single output. The MPC block would allow you to define the second process variable as a constraint, which the MPC block takes care of. James would be able to talk to that better than I. I think these types of applications are what make control systems fun, when you design the right strategy and get awesome stable control results. Good luck.

Andre Dicaire

In reply to Andre Dicaire:

Excellent suggestion by Andre to consider the MPC or MPCPro block.  There is no license required for a one MV (output) the MPC, MPCPro (or MPCPlus) blocks!  3527.6-14908 - Caldwell_Beall _FINAL.pdf  The attached presentation from the 2017 Emerson Global Users Exchange explains how easy it is!  Let me know if you have questions.

In reply to James Beall:

James,
Thankyou for the reply. Unfortunately, in our case, it seems there is nothing to stop the non selected controllers going to full saturation, which is not satisfactory. I understand exactly your description, and it is what I would expect to happen. Sadly, it doesnt.
Control output signal selection with bumpless transfer is a basic and essential part of many control schemes. Surprisingly, many control systems dont supply any standard features to make this happen, instead, the user has to first realise he needs the bumpless transfer capability, then he needs to configure logic around the signal selector to make it happen. Many installations I visit have neither capability, so soldier on with poor control.
I understand, that the DeltaV system control output signal selector should provide the necessary functionality, but our on-site testing indicates that for some reason, in our case, it doesnt.
As such, I will proceed with configuring some logic around the signal selector to make it happen.

Once again, thankyou for your input.

Regards
Jeff Richards

In reply to jeff richards:

I think what you are looking for is "Dynamic Reset Limiting" this is an option under the FRSIPID_OPTS parameter of the PID block, (I normally check this by looking at the module template for a master PID loop, it has this option enabled but the slave template does not). BTW when using this with a slave PID loop the slave should have: use PV for BKCAL_OUT under control_opts.

I think there is a KBA for this somewhere, I don't have access at the moment to look for it.

Try this testing this option, it normally keeps the non-selected loop (using the BKCAL status of not- selected) to keep the PID output within about 3% of the selected loop. Sometimes I have had problems with multiple control selector blocks and have used CALC blocks to manipulate the BKCAL value but with one selector block it should work as you would like it to.

Regards
Chris

In reply to Chris:

Chris,
Thanks for the reply. Yes, activating the dynamic reset limiting within the PID controller is what is required.
All works fine now.

Many thanks

Jeff Richards

In reply to jeff richards:

Jeff,
This is interesting! It should work without Dynamic Reset Limiting but this tells me there is a lack of status propagation. The most likely suspect is a an "Output Parameter" in the path of one of the BKCAL_OUT of the splitter block that has a "Type" chosen as "floating point" instead of "floating point with status" (I know because I have been guilty of this a time or two!). This prevents the status from being propagated with the value. The status of a signal is vital for all of the controls to work (it is in the ISA/IEC standard that DeltaV follows). I will be glad to look at the configuration if you want to send it.
James

In reply to jeff richards:

This discussion is getting confusing. Dynamic Reset Limiting addresses issues with cascaded PID loops, where the output of a slave loop becomes limited but the SP of the loop can still move. For the issue to be resolved by enabling this option, something is not as it seems.

I'm glad that the issue appears to be resolved, but if we leave it there, I don't think we've actually fully explained this.

Bottom line, the Control Selector works to provide bumpless transfer as a constraint PID overrides the primary controller. The transfer happens when the contraint PV reaches the constraint SP and the PID OUT value equals the primary controller output, and moves through this as the PV passes through SP, causing the selector to switch to the contraint PID.

You've indicated that your constraint PID (input 2 or 3 to the control selector) is winding up. If the BKCAL signal is properly connected, Reset action on this PID is disabled with the Status of NOT-SELECTED. This status forces the PID into Integral Tracking. The OUT value still moves based on proportional action, but there is no windup. Also, this is not a status that engages Dynamic Reset Limiting. So this is confusing.

If you look at the Constraint PID when it is not selected, what is the value and status of its BKCAL_IN?
If you force the PV or INPUT of this PID, keeping the status of the input as GOODNONCASCADE, not limited, the OUT value should equal the BKCAL_IN value plus the (PV-SP)* GAIN. As you move the PV toward SP, the OUT should move toward the BKCAL_IN value, with no reset action or windup. i.e. if the error is fixed, the OUT will track BKCAL_IN with a fixed offset.

They point is that the OUT value could be maxed, and appear to be wound up, but this is due to proportional term and is not wind up. If the BKCAL_IN is some other status, then the loop is not connected properly with a control selector.

Side bar on Integral Tracking:
As for integral Tracking, someone explained it to me once that I'm going to share. The OUT of a loop is the sum of the PID terms. Under steady state at Setpoint, the Proportional term is equal to 0 (GAIN * error = 0 when SP = PV). The Derivative term, if enabled, is also 0 when the PV is at steady state. So the only term left to make up the current PID OUT value is the Integral Term. So Integral Tracking simply means we force the Integral term to track a value, but the OUT of the PID is still free to move due to Proportional or Derivative action. Proportional is your primary mover of the Output .

The active proportional term is what allows the control selector to work with PID blocks to set constraint control. DeltaV Implements this through the BKCAL signal and the sub status of the GOOD CASCADE status. When the status is not selected on the BKCAL_IN of the PID, the integral term tracks the value and the of the PID block moves due to either proportional action of the PID or if the BKCAL _IN value changes. It is a dynamic tracking feature.

Andre Dicaire

In reply to Andre Dicaire:

Good points by Andre. For the benefit of others who may read this post, I have had some off-line communication and investigation with Jeff on this issue. We indeed found that some parameters in the BKCAL and final CAS_IN did not have a status attribute (were "Floating point" instead of "Floating point with status"). This is what was causing the problem. The Dynamic Reset Limiting (DRL) might have made it better but it won't be a complete solution. DRL is an additional feature that can be helpful in the situation that Andre described which could be applicable in this case if the downstream module was a PID loop instead of an Analog Out. When you use DRL in an upstream loop, you should use "Use PV for BKCAL_OUT" in the downstream loop. (There is actually an application to use this for an AO block but that's another post!) So, the proper configuration of the an override application per the Books On Line documentation will work and not cause windup. Hope this helps everyone! Feel free to comment or start a new post if more information is needed.

In reply to James Beall:

By the way, the reason I can detect the impact of missing status is that I have made this mistake a few times on my own! :)