Persistent offset in CAS master?

Hello!

I have a persistent offset which shouldn’t be there. We were running a cascade control strategy on a liquid-vapour heat exchanger and found a persistent temperature offset despite having Reset in the master loop.

This is on one of our lab heat exchangers (I’m a Lab Instructor for a two-year program teaching measurement & controls). My students were trying out the theory that the inner loop of a cascade system does not require integral action – but it appears that the lack of integral on the inner loop affects the integral of the outer loop?

Can you confirm if I’m seeing this correct (and confirm my BKCAL settings)?

The attached trend shows a persistent 1’C offset (pink PV vs grey SP). Yes, it’s only an error of 1/120 of full scale, but the OUT (cyan) is not changing over many minutes despite the error. This is in response to a load flow disturbance (purple).

Here’s what I checked:

 Inner loop (PC-5107)

• PV scale is -100 – 250 kPa
• OUT scale is 0-100%
• Tuned with Gain of 1.7, Reset = 99999s and Rate = 0
• CONTROL_OPTS has ‘Use PV for BKCAL_OUT’ checked.

 Outer loop (TC-CAS-5120)

• PV scale 0-120’C
• OUT scale -100 – 250 kPa (and yes James, ARW Hi is 250 and ARW Lo is -100)
• IDeadband = 0
• Tuned with Gain = 3.5, Reset = 25s, and Rate = 0.
• FRSIPID_OPTS has ‘Dynamic Reset Limit’ checked.

The BKCAL path is non-trivial, as I have a cascade PID master, PID slave, CTLSL (for a low select), BG (for CAS/MAN station with tracking), and then finally the AO. The control studio screenshot is a sketch showing how the blocks are connected, the actual configuration is done using multiple modules.

My other 6 groups tuned their inner loops with PI-control, and did not observe an offset on their outer loops (“their Outie is adept at temperature control”)

 

Am I missing a setting which affects integral action?

 

Many thanks,

Chris

• iFix #Operate #Graphics
• PID

Chris Goetz

• 3 Apr 2025 9:31 PM
• Cancel

6 Replies

• Mark Coughran

  

  • 4 Apr 2025 1:47 PM

  Why are you trying to avoid using integral action in the inner/secondary/slave loop? Most of these are flow and pressure loops, which need integral action. I believe the outer/primary/master loop cares only about its PV and is unaware the settings of the inner loop. It only needs its PV to respond in a linear fashion to its OUT with minimal dead time; the inner loop exists to provide these.

  • Cancel
• Andre Dicaire

  

  • 4 Apr 2025 5:47 PM

  In reply to Mark Coughran:

  I agree with Mark. The inner loop, Flow, is a self regulating loop and has no inherent integral action. To return to setpoint, which is driven by the Master loop, the Flow loop needs integral action. An integrating process like a level will change it's PV over time as long as the in and out flows are unbalanced. Adding Integral action to a level loop can cause the inherent integration and the PID integration to interact and result in oscillations. Often these levels are tuned with P or PD algorithms as the level continues to change until the control flow matches the wild flow.
  
  Your flow loop could get back to a 0 error at some point but without integral action, the Flow loop cannot close the error over time. You inner loop should be tuned independently to provide its best response, or desired response (fastest is not always bestest). Once the flow is tuned, your outer loop sees the Flow loop as its "control Element" and directs it to provide a requested flow, rather than a valve position. Given changing process conditions and hysterysis, a given implied valve position does not result in the exact same flow and a slow level loop takes time to see that impact in the level. The Flow loop sees it right away and adjusts to deliver requested flow. So, tune you Flow, then tune your level.

  Andre Dicaire

  • Cancel
• Chris Goetz

  

  • 4 Apr 2025 7:18 PM

  In reply to Andre Dicaire:

  Thanks for your replies.
  I agree that this setup is a bit academic. The inner (pressure) loop would require integral action to remove (inner) offset - although technically the outer (temperature) loop should not care if there is offset in the inner loop as the outer should just request more of the inner loop.
  My question was more about the algorithm than the application – I don’t see why the outer loop did not appear to integrate the error and increase its output. I'm wondering if there is a setting that I'm missing.

  • Cancel
• Andre Dicaire

  

  • 4 Apr 2025 9:05 PM

  In reply to Chris Goetz:

  The outer loop is a Temperature TIC_MSTR. Temperature loops are also Self Regulating, usually, and as such don't integrate their PV, which would lock the PID algorithm at a given point with an offset from Setpoint.  I think it is because DeltaV is looking for a change in error, not just an error.  Once the Temperature becomes stable, there is no further movement of the Output, even though there is still error between PV and SP

  Andre Dicaire

  • Cancel
• Mark Bendele

  

  • 7 Apr 2025 11:30 PM

  In reply to Andre Dicaire:

  Try unchecking "Use PV for BKCAL_OUT" in CONTROL_OPTS for the inner loop. External reset feedback is great when you have override control or a saturated inner loop. It prevents windup. In your demonstration, you have created something similar with the offset in the inner loop. I seem to remember James Beale having written a contribution to this forum about dynamic reset limiting that you might find helpful. Sorry I can't send you a link, but for some reason I can't do searches here anymore.

  • Cancel
• Matt Stoner

  

  • 8 Apr 2025 12:13 PM

  In reply to Mark Bendele:

  Maybe it is in this post?

  • Cancel