Emerson Exchange 365

• Not Answered

Splitter FB

I have a PID controller feeding a Splitter FB with two FFAO. The Splitter FB setup is default 0,50,50,100 to 0,100,0,100 with OUT_1 holds. Recently with the PID in Manual Mode and 0% output, the valve #1 output changed to 100% open. Based on Event file, there were number of FF I/O failures typically lasting less than one second (PID Execution is at 1 second) with no impact, but once FF I/O failure exceed 1 second then, the Splitter ignored the PID output command and proceed to Y12!

Has anyone seen this issue? Any solution?

Regards;

Hassan

HassanJalali

• 19 May 2021 7:27 PM
• Cancel

3 Replies

• Mark Bendele

  

  • 20 May 2021 6:43 PM

  If the splitter sees both BKCAL_IN_1 and BKCAL_IN_2 with bad or NotInvited status, its BKCAL_OUT will go to 50 with NotInvited status, which causes the PID output to go to 50. If valve #1 goes good first, then the PID output will go to 0. If valve #2 goes good first or if both go good at the same time, then the PID output stays at 50. The splitter needs to see its BKCAL_IN_1 go good at least one scan before BKCAL_IN_2 for the PID output to stay at 0.
  
  I have not had this happen with bad signals, but I have seen it with mode changes. I have a splitter that feeds two PIDs downstream. When the operator puts them both in CAS, the result depends on which he puts in CAS first. I use tracking to force the upstream PID output to go where I want it at the moment both downstream PIDs are in CAS.

  • Cancel
• Andre Dicaire

  

  • 21 May 2021 5:14 PM

  Initialization of the SPLITTER can be tricky. Understanding its behavior is key to determining the "right" behavior for the abnormal conditions that can come up, such as your FF IO failure conditions.
  
  The SPLITTER will initialize with the first downstream block that transitions to CAS mode, and in your case, this is AO2, that causes the SPLITTER's BCKCAL_OUT to send 50% to the PID. The valve connected to OUT1 has not initialized yet and so it ignores this signal. The PID is now able to move from IMAN and to the Target mode. The PID OUT value may move back toward 0 or increase beyond 50 depending on PV/SP driving AO2, via OUT2. Meanwhile, the other AO becomes Good status and initializes OUT1 of the SPLITTER. The SPLITTER has a ramp time that is used to move the SPLITTER's OUT1 value to the expected value for OUT1 based on the CAS_IN value from the PID.
  
  Depending on the PID block closed loop response, SP track PV setting, MODE, and how long between the AO blocks transitioning to CAS, there are many cases where the SPLITTER will be ramping the OUT1 to the defined range, leaving you with AO1 at 100% and AO2 at 0, and a disturbance in the process.
  
  In some cases this would be the desired behavior, or say the OUT1 was set to be 100-0, so that at 50% on the PID, both valves are at 0. In a progressive arrangement like yours, initializing the OUT2 before the OUT1 will engage the ramp time but will likely result in opening AO1.
  
  I can think of two ways to address this, and there are likely many others.
  
  You could track the PID block when AO1 is in IMAN, or both Valves are in IMAN. This way, the PID OUT would remain at 0, or where ever you decide it should be. Maybe your track value is the last value of AO1. If the AO blocks are only to ever be in CAS, then track until they are in CAS, or at lease AO1 is in CAS.
  
  Or you could use an expression (CALC or ACT block) to set the Target mode of AO2 to MAN if AO1 goes to IMAN. The question now is should AO2 continue in CAS if only AO1 is bad? You will have to decide how to handle the various possibilities based on the Process.
  
  If you're handling transient conditions caused by communications, you don't want to move either valve as this would disrupt the process. Of course, addressing the communication failure on the FF segment is paramount. Bottom line, you have to decide all the failure scenarios and then manage the PID and AO blocks to achieve the desired recovery. Simple is always better. Unlikely scenarios don't necessarily need an optimized solution. Focus on the main use cases which may be good enough for the less likely outliers.

  Andre Dicaire

  • Cancel
• HassanJalali

  

  • 24 May 2021 5:15 PM

  In reply to Andre Dicaire:

  Andre;

  Thank you for your detailed response.

  • Cancel