I am having an issue when we switch from flow control to Pressure control and start ramping we get a dip in the output which results in a decrease of flow.
I will try to explain the best I can.
This is what the feedback loop looks like, it has been this way for years.
We start with the FC in AUTO with the SP set to the FLOW_SP typically 400-450 lpm this is to purge the air from the filter press. At this point the pressure is very low >0 but <1 maybe .05 Bar.
'^/FC545100/MODE.TARGET' := AUTO; '^/PC545300/MODE.TARGET' := MAN; '^/FC545100/SP.CV' := '^/FLOW_SP.CV';
Once we have purged the air we switch to pressure control and set the ramp rate.
'^/FC545100/MODE.TARGET' := ROUT; '^/PC545300/MODE.TARGET' := AUTO; '^/PC545300/SP_RATE_UP.CV' := 0.00070;
Wait 15 seconds then set the SP to the PRESS_SP typically 5.5 bar.
'^/PV.CV' := '^/COMMAND.CV'; '^/COMMAND.CV' := 255;'^/PC545300/SP.CV' := '^/PRESS_SP.CV';
This is where we see the Output dip it will go from roughly 58% to 52% sometimes as low as 48% this results in a flow decrease of 150 to 200 lpm if the operators don intervene.
We also see the SP_WRK drop to 0 and start ramping from there.
Firstly does that feedback loop look correct?
Second how can we maintain the output when we switch to ROUT so that we do not get that dip in flow.
Thank you in advance.
In reply to Mark Coughran:
Andre Dicaire
I have added screen shoots and FHX for the FC and PC (hope they come through ok).
For this question...The PC block should be showing its OUT parameter following the FC/OUT, via the FC/ROUT_OUT wired to BKCAL_IN on PC. When FC is in AUTO, PC should be in IMAN, and PC OUT should follow FC OUT. Is that all happening?
I believe it is happening like that.
I have started a trend for the BKCAL_IN and the ROUT_IN. I need to wait for the process to run again for some data.
thank you for the help.
Files may need to be changed to .FHX
P540-2_CTRL.txt
FC545100.txt
PC545300.txt
In reply to Andre Dicaire:
had to do a quick test. Two PID loops connected via ROUT of secondary loop.
Connecting ROUT_OUR to BKCAL_IN allows the primary PID to follow the OUT Value and take control of secondary PID/OUT in ROUT mode. So I don't see an issue with ROUT_OUT to BKCAL_IN. As to why the FC/OUT value is dipping, and SPWrk is going to 0, you will need to provide more detail as to which loop is causing the dip. Once in ROUT mode, the Flow PID would ignore its SP-PV error and any SPWrk value. If the ramp is in the PC, I'm leaning to how that PID is configured to run the ramp. If PC loop is in MAN, does Output stay stable on move to ROUT in FC? And dip occurs on PC mode going to Auto? I'd be looking at the PC loop.
Which brings me to linking modules in a third module. Module blocks do not influence the execution order of control modules, they simply facilitate integration of one module with another, like a Cascade Outer loop hosting the inner loop in a Module block so you can easily connect the BKCAL and control signals between them. They both execute at their configured execution time and independently set in the controllers schedule. Cascade control relies on the inner loop having a much shorter time constand than the Outer loop, allowing the inner loop to improve control of the outer loop.
By using a third module to pass data from PC to FC, you introduce module execution order latency. You cannot control Module execution order as this is set by the Controller's schedule. You can run modules faster or slower to reduce effecitve latency but you cannot force execution order by pulling modules blocks into another module. By design, you should directly reference the PC/OUT value from the FC module. You can still have the overview module to visualize and control both modules from this module, but understand that you are not controller module execution order here, and you are adding closed loop IO latency between the PC module and the FC Out block.
In the case of an MPC block that takes over control of PID Outputs in ROUT, the time to steady state of the MPC is typically much longer and being model based is not dependent on feed back the same was as a PID block. Moving the OUT signal from one PID block to another (from flow control to direct pressure control) using separate modules means you add latency to the Pressure loop. How much latency that can be tolerated by the Pressure loop depends on your time to steady state in closed loop control and the pressure time constant in open loop. But Feed back control with PID works best with minimal IO latency and you should have no more than one half the PID execution time for your IO latency.