Emerson Exchange 365

• Not Answered

Preventing wind-up of a master loop that has 3 slave loops

We have recently programmed a cascade control strategy with a master loop (hydrate inventory) connected to 3 slaves loops (calciner flowrate), with a rate limiter block on the master loop's output. To prevent reset winding-up on the master controller, we would like to use its PID block BKCAL_IN function, but when one of the 3 slaves loops comes out of CASC mode (in either AUTO or MANUAL mode), the master loop controller goes in IMAN mode and tracks the slave loop’s PV. The slave PV and STATUS seem to both affect the master loop with the BKCAL_IN function.

 

Could anyone using a similar strategy in Delta-V please advise us on the proper way to set-up such a loop configuration (one master & multiple slave loops), more particularly using some type of intelligent slave loop tracking?

Michael Reid

• 19 Dec 2019 6:14 PM
• Cancel

7 Replies

• Trista VanDerVeeken

  

  • 19 Dec 2019 7:15 PM

  I believe what you want to use are splitter function blocks, which will give you the status handling you are looking for (master loop will not go to IMAN until all loops are out of CAS), the IN_ ARRAY and OUT_ARRAY will be the output range of the PID.  Since you have 3 downstream loops, you will want to use 3 splitters (this is for symmetry and is recommended).  This will give you outputs to 4 downstream loops.  Since you only require 3, you will want to use a calc bock as a dummy placeholder for the fourth.  The expression I used in the CALC block is:

  OUT1.CV := IN1.CV;

  OUT1.ST := 204;  

  This status will always be GoodCascade NotInvited NotLimited so it will not affect the status handling of the real loops.  

  Below is an illustration, keep in mind that the BG_SLV4 is where the calc block will go as a dummy placeholder.  You will wire the BKCAL_OUT of SPLTR1 to the master PID BKCAL_IN.

  

  • Cancel
• Michael Krispin

  

  • 20 Dec 2019 1:17 PM

  In reply to Trista VanDerVeeken:

  In principal correct. I would delete SPLTR5 and it also save the calc block . Use from SPLTR1 the OUT2 direct to the Slave 3 and link BKCAL_OUT to SPLTR1/BKCALIN_2. IN and OUT Scale for all Splitter are 0-100%.
  The ratio blocks need to connect between the SPLTR/ OUTx and CAS_IN of each slave
  Take care for the FB execution order.

  • Cancel
• JoshC

  

  • 20 Dec 2019 1:38 PM

  In reply to Michael Krispin:

  Trista is correct.  AP-0600-0039 recommends having the CALC block. Without it and the additional splitter there isn't sufficient symmetry from the perspective of the first splitter block. This figure is from the knowledge article:

  

  • Cancel
• Michael Reid

  

  • 20 Dec 2019 2:07 PM

  In reply to Trista VanDerVeeken:

  Thank you! We did think of using a splitter block for this function.

  • Cancel
• Michael Krispin

  

  • 20 Dec 2019 2:54 PM

  In reply to JoshC:

  I don't know about that article. I had used as I has described but without the ratio FBs and it worked fine with three slave controller in a Temperature Control with several cooling loops (Cage/Jacket in two stages). Each of the slaves as split range. Since all splitter are just 1:1 through blocks, all slaves get the same output from the master.

  • Cancel
• JoshC

  

  • 20 Dec 2019 7:06 PM

  In reply to Michael Krispin:

  Normally it wouldn't be a problem. The issue is status propagation of the downstream blocks since AO3 connects directly to the first splitter. When the splitter transitions from IMAN to AUTO (which happens on partial download or controller switchover) it initializes itself to AO3 since AO1 and AO2 have to travel through the second splitter block. With symmetry, they all initialize the same scan and there is no (potential) disruption of the process.

  • Cancel
• Michael Krispin

  

  • 21 Dec 2019 4:19 AM

  In reply to JoshC:

  Ok, now I see where you come from. After download/redu-switch on the PID CM (including all splitters) the BKCAL_IN of the both slaves behind the 2nd Splitter need max one cycle longer to bring their BKCAL_OUT status to the 1st splitter due to the FB execution order. In my approach I did not used module block for the slaves into the PID-CM. I used ext. references for CAS_IN and the BKCAL_IN and read direct the BKCAL_OUT from the slaves. Havn't seen issues on download of the master in my process, but that should be done anyway with more care in a critical process

  • Cancel