Emerson Exchange 365

• Not Answered

Action block's expression writes to PCSD based FF-AO block to change Auto to CAS and its results no change of mode means its stays in AUTO mode.

1) If Selection = Heater B then this expression write target mode: Auto to FF-AO block (PV001A) and CAS to FF-AO block (PV001B). But FF-AO (PV001B) not changing to CAS, means it stays in AUTO mode.

2) If Selection = Heater A then this expression write target mode: Auto to FF-AO block (PV001B) and CAS to FF-AO block (PV001A). But FF-AO (PV001A) not changing to CAS, means it stays in AUTO mode.

Note: If we do manually change of mode of individual FF-AO block its moves from Auto to CAS and vice versa.

Please send your feedback or any resolution on this issue or do we have any hotfixes for this issue.

• 13.3.1
• control logic
• DeltaV 13.3.1 version - Selection of Control Valve logic
• DeltaV

Mohan Kannan

• 7 Jun 2021 7:13 PM
• Cancel

4 Replies

• Paul Hughes

  

  • 7 Jun 2021 7:22 PM

  This is an old problem. The XFER block does not carry out proper AUT/CAS handshaking. To explain it here would take a while, but there are around 2-3 cycles for a slave loop to accept the CAS in from a master. Somewhere in my repository I have a solution to this. Would have to go and locate it.

  • Cancel
• Andre Dicaire

  

  • 7 Jun 2021 7:37 PM

  I'm wondering if this is related to how FF defines CAS as both Auto and CAS bits set: Auto =16, CAS=32, but FF CAS= 48. Try using the number 48 instead of CAS.
  
  And why have the Transfer blocks at all? A splitter with both outputs set 0-100 would allow you to connect both FF-AO blocks to the PID. Since you are only placing one AO in CAS, and writing the SP to 0, only one of the blocks would follow the PID while in CAS. The Splitter handles the BACK CAL status and value propagation.

  Andre Dicaire

  • Cancel
• Matt Stoner

  

  • 7 Jun 2021 10:04 PM

  In addition to what Andre stated there are some other issues in play here. You can't constantly write to a fieldbus device parameters from an expression every scan and should only do a direct write if it is required (at least in the past...more later). Which means you need to put checks if the value that will be written is different than the value that is there before actually writing. Constantly writing has been known to burn up memory in the devices and then stops communicating entirely. Unsure if this has been hot-fixed as I haven't done Fieldbus since Charms was released a "few" years ago but I doubt it has. You also are writing the BKCAL_IN.CV to the BKCAL_OUT.ST after you set using the .CV on the line above, second set should be using .ST instead of .CV.

  Agree with Andre that a Splitter might be the best option here. Otherwise you will have to mess with the proper status passing and possibly extra acknowledges logic based on mode changes by operator. If you do go this route I would suggest using a single CALC block and then pass the appropriate values and statuses based on the selection instead of the NOT, ACT and 3 XFR blocks because XFR passes worst status of Selected input and the selector and not just the selected input. Not sure why are you setting the mode of the AO block at all? If in AUTO that means an operator could change the output of non-selected AO which might mess up your control scheme. If the selected Loop goes to AUTO then the proper status needs to be passed back so the Master Loop goes to IMAN and doesn't continue to attempt control. I threw together quickly the below that might get it close (no testing...) if you don't go with the Splitter block but you may have to put other logic for switching between the selection. This also doesn't do anything with Mode or writing SP so you don't have to put all the extra logic in but if you want to do that this logic will get more complicated.

  

  • Cancel
• Mohan Kannan

  

  • 8 Jun 2021 11:42 AM

  In reply to Matt Stoner:

  Thanks Matt, its works. Appreciate your support.

  • Cancel