Emerson Exchange 365

• Not Answered

Cascading with the Calc block

So I'm new to DetlaV, having spent most of my automation career in a Ladder Logic/Rockwell Automation environment. I'm trying to cascade two FCVs, one primary, in order to fill a tank. I'm using XFR and CALC blocks as my input to my PID for the main FCV with a simple expression:  

IF 

'TANKLEVEL/PID1/PV.CV' >75 THEN 'OUT1>CV' := 0

ENDIF;

IF

'TANKLEVEL/PID1/PC.CV' < 45 THEN 'OUT1.CV' := 1

ENDIF:

For the other FCV, I'm using this:

IF

/TANKLEVEL/PID1/PV.CV' < 60 AND 'TANKLEVEL/PID1/PV.CV' > 75 THEN 'OUT1.CV' := 1;

ENDIF;

IF

/TANKLEVEL/PID/PV.CV' < 45 THEN 'OUT1.CV' := 0

ENDIF

The control philosophy is basically this: IF TANKLEVEL >75 then SECONDARYVALVE = CLOSED and PRIMARYVALVE = CLOSED

Else, if TANKLEVEL < 60 and > 45, then PRIMARYVALVE = OPEN and SECONDARYVALVE = CLOSED

Else, if TANKLEVEL < 45, then PRIMARYVALVE = OPEN and SECONDARYVALVE = OPEN

Appreciate any assist here...am knee-deep in learning DeltaV.

Barrick_JA

• 20 Jul 2017 4:36 PM
• Cancel

10 Replies

• Rachelle McWright

  

  • 20 Jul 2017 5:56 PM

  Hi Barrick_JA , I took the liberty of moving your post here, to the DeltaV group, where you should get a much quicker response. Thanks for joining us in the EE365 community!

  Best Regards,

  Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • Cancel
• Brian Hrankowsky

  

  • 21 Jul 2017 8:59 PM

  The description above makes it sound like you are working with discrete valves – is that right?
  
  Your description does not sound like a cascade strategy as you are setting the valves based on the PID PV, not the PID Output. Can you explain more what you mean?

  • Cancel
• Andre Dicaire

  

  • 21 Jul 2017 10:32 PM

  Your description looks like you are using Discrete values as Brian points out.
  
  Please describe what this tank is doing and the type of valves installed (0-100% modulating or ON/OFF), and how the level is to behave with respect to Set Point. (is this a surge tank)
  
  What happens if the level is between 60 and 75? It looks like you are creating a gap where by the primary valve will hold its state, such that as level increases, the primary valve stays open until level reaches 75, and then closes. It remains closed until the level drops below 60, at which point the primary valve opens. Below 60 the Primary valve is always open. The secondary valve is open when the level is below 45, and then closed when level is above 45.
  
  If this is correct, a couple of condition blocks will accomplish this and it is much easier to manage and trouble shoot. The expression must evaluate to true or false.
  
  For secondary valve: TANKLEVEL < 45.
  
  For Primary Valve: (TANKLEVEL < (60 + (15*('/OUT_D)))
  ( When the level is less than 60, the OUT_D is TRUE. This makes the compare value 75. When the level reaches 75, the OUT_D goes false, and the compare value drops to 60. The OUT_D remains off until the level drops below 60, at which point OUT_D goes TRUE and the compare value goes back to 75. This creates a hysteresis zone. If you want the OUT to turn on above 75 and off at 60, you use the upper limit and subtract the hysteresis of 15. )
  
  The CALC block is often used because of its flexibility. However, for simple On Off conditions, the CND block is more efficient, and by using multiple blocks, the logic becomes more visual and compartmentalized. You can also add a descriptor, adjust the On Delay of the condition, and individually enable/disable the block. There is also a failure mode for the condition to either go FALSE, go TRUE or Hold Last value incase the expression data source goes to a BAD status.
  
  You can also create some tuning parameters to hold the three numbers used here, allowing you to tune the values rather then edit the expression and download the change. That's a choice as either way will work.
  
  If on the other hand, you want the Primary valve to modulate and control the level with a PID block so the user can adjust setpoint for the level, and these valves use AO blocks in stead of DO blocks, you might be better off with a splitter and configure the PID with Gap control. The splitter allows you to ramp the valves based on the PID output. The way you have described this, you are not using a PID block as you logic is driving directly from the Level, not the PID/OUT. Check out the Gap control and splitter blocks in Books on Line.

  Andre Dicaire

  • Cancel
• Steve Linehan

  

  • 23 Jul 2017 8:02 AM

  In reply to Andre Dicaire:

  I would strongly encourage you to use native blocks to do this. Embedd the blocks in a composite to save space on your module. Input parameters PV, HI_HI, HI, LO. Then use CMP1 wire PV (DESC_VAL) to this and HI_HI (COMP_VAL1) and HI (COMP_VAL2). Use CMP2 and wire PV (DESC_VAL) and LO (COMP_VAL1) to this. Then wire CMP1/LT to OP1 (Primary). Then drop an OR block onto the piagram. Wire CMP1/IN_RANGE to first IN and CMP2/LT to IN2. Then Wire the OP of the OR to OP2.
  
  This will allow non technical staff to see what is going on with the logic. While CALC blocks are great there is a tendancy to overuse them. By doing in a linked composite you have developed a piece of code that you can reuse eslewhere .

  • Cancel
• Barrick_JA

  

  • 24 Jul 2017 5:30 PM

  In reply to Andre Dicaire:

  Hi Andre, while they are control valves, they sort of function as on/off...sort of...based on control narrative provided. But, yeah, the goal is to keep the tank level at around 60%. But still shut down valves when it hits 75...no higher.

  • Cancel
• Barrick_JA

  

  • 24 Jul 2017 5:48 PM

  In reply to Steve Linehan:

  Is there a way to embed graphics? I've taken a couple screenshots of what I've already done.

  • Cancel
• Matt Stoner

  

  • 24 Jul 2017 5:53 PM

  In reply to Barrick_JA:

  Click the "Use rich formatting option" on a reply and then you will get some options on adding more things.

  • Cancel
• Barrick_JA

  

  • 24 Jul 2017 6:04 PM

  In reply to Matt Stoner:

  

  • Cancel
• Lou Heavner

  

  • 24 Jul 2017 6:06 PM

  In reply to Barrick_JA:

  I would have done essentially what Andre suggested but in a less clever and easier to visualize way. Three conditions and 4 action blocks. Conditions are "greater than the specified levels", which could be set up as adjustable parameters. The action blocs would open or close the valves. The secondary valve action blocks would share the same Condition block, but one would be configured with a NOT block in front of it. Use PDET blocks to provide a single shot to the action blocks. You can still do regulatory control and impose the overrides. Use the PID tracking feature. You could keep the logic described above with the secondary valve and instead of action blocks for the primary valve, write the 0 or 100% into the track value via a selector an use the conditions to enable track and choose which input passes through the selector. You could also use the ROUT mode with the PID loop and write to the OUT in ROUT mode. Just a matter of preference I would use tracking, personally.

  • Cancel
• chip.burge

  

  • 24 Jul 2017 6:52 PM

  In reply to Barrick_JA:

  Don't forget to clean up the function block execution order.  The order is indicated by the little numbers in the bottom right of each function block.  Dashed lines between function blocks indicate a value from later executing block feeding into a earlier executing block.  This is normal behavior for some parameters e.g. BKCAL.

  Click "Set order" from the diagram tab in CS.  The next function block you click will have its execution order set to 1.  If you shift+click a function block you can set this internal starting point to the value of the block that you shift+clicked.  The next FB you click will be assigned the order of the number you just selected + 1.

  • Cancel