Emerson Exchange 365

Splitter block "configuration symmetry" advice / discussion

Dear all,

I have a unique module where the PID output is wired to a "Splitter" (SPLTR) block to control two valves - large and small kickback valves on a compressor. From time to time - randomly but mostly when I'm away from the plant - it experiences some errors and sheds to "MAN". There is no evidence of issues with field devices. The journal shows an issue with the splitter, which clears in a few scans:

I read in KBA AP-0600-0039 that - at least in v13.3.x and earlier - it is recommended to ensure the module has "configuration symmetry" when the output of the primary (closest to the PID) splitter is connected to other blocks. In my case, OUT_2 passes through a LIM block which is then connected to the AO for the "large" KB valve. OUT_1 is wired to a "high select" block (CTLSL) which serves in a constraint control scheme - the override control input originates in a separate controller.

In my scheme I think I've violated the recommendation to ensure initialization / handshaking connections (BKCAL_IN) since OUT_1 is passing through a CTLSL block which also provides handshaking and initialization signals. Do you agree? Is configuration symmetry for SPLTR blocks still recommended in version 14.3.1?

The circled CALC block is triggered by the controller's PAVAIL to make sure initialization is bumpless on a redundancy switchover. There is one for each AO block.

John Rezabek

• 17 Aug 2020 2:41 PM
• Cancel

3 Replies

• Andre Dicaire

  

  • 17 Aug 2020 6:22 PM

  I don't think the IO output failure is due to the internal design of the module. The IO Output affects the FFAO connection and back calculates to the Splitter. I cannot read the time stamp of the two IO Output failure messages. Are they in the same scan of the module (a few milli seconds difference) or are the in different module scan. These are the Error cleared messages. We should look at the order of the messages and understand the SOE of the messages.
  
  The balancing of the logic after the splitter tries to address how the Splitter will initialize, and that both paths will cycle through initialization in the same number of scans. The splitter will initialize to the first BKCAL that initiates Cascade. When both provide this signal, the Splitter will initialize the PID using the first OUT path. If you don't balance the logic, the Splitter will typically initialize to the shorter path. I think that when one path initializes first, the second will use the Splitter's balance time to ramp the second value to the splitter's target value and once there, normal signal propagation will continue. Note also that a longer path will delay the back calculation signal to the Splitter, when a downstream block is moved out of CAS, or to LO or IMAN. Normal control signal flow does not matter as both paths will complete in the same module scan.
  
  I think we need to focus on why the IO Output Failure is occurring. This is often caused when the DeltaV Module executes faster than the Output value can be communicated to the field device. Especially so when the value clears on the next scan. If the FF segment macro cycle is close to the module scan rate, the module execution and the segment scheduler could occasionally result in a lining up of two module writes within one macro cycle.
  
  This is not necessarily a problem that requires action so much as understanding. But I'm thinking this is where I would start to solve the IO Output error, not the module design itself.

  Andre Dicaire

  • Cancel
• John Rezabek

  

  • 18 Aug 2020 1:46 PM

  In reply to Andre Dicaire:

  Andre - thanks for the feedback. Indeed the macrocycle time of the segment is the same (1 second) as the module execution - but it has been this way for many years. Didn't experience these issues until the last 6 - 12 months. The segment doesn't have much else on it and the macrocycle can be reduced to 500 ms, which we will try. For me though it doesn't explain why the errors are so sporadic (episodes are weeks apart, but have been known to come in a few times during a 12 hour shift, when they occur). There is no record of communication errors on the H1 card side . . .nor does anything show up in AMS or Audit  Trail.

  

  • Cancel
• Andre Dicaire

  

  • 18 Aug 2020 9:45 PM

  In reply to John Rezabek:

  The way I'm seeing it is that if you have an output that is written to a second time before the IO subsystem has communicated this value to the output, the IO Output failure is raised to indicate the IO subsystem is not able to react to the control signal changes you've sent to it. It's informational, and not necessarily a concern, but would be a nuisance in th event log or if this trips a module alarm.
  
  With a module and macro cycle both set to 1 second, both tasks run asynchronously, so there is definitely a random aspect to this. If the tasks were offset by 500 ms, we would not see a problem. But overtime, or as a result of a download or a switchover or whatever, if the periods line up, then there is a possibility that a write from the module is executed immediately after the macrocycle is updated, and due to possible jitter in the module scheduler or the macrocycle, the module executes milliseconds earlier and results in an Output failure.
  
  It could be very sporadic, and most of the time no error is seen. Timing of the module execution is considered on time if it is within 10% of the configured scan rate. A module is scheduled in a time slice along with other modules and although the slice itself may be accurately triggered, the sum execution time of the modules can vary based on conditional logic in the modules, and so the actual time within the slice each Output function executes can vary by a some milliseconds.
  
  There's no way to see this level of shift other than observing the timestamp on events from the same module. You might see the millisecond value on a 1 second module vary, which tells you the module's shifts back and forth in the schedule.
  
  It's a theory right now. If you speed up the Macro cycle to 500 ms and the problem goes away, I'd mark it as proven. If these IO output failures still persist, I am not sure what the cause would be. I also think that if you changed the macrocyle to 500 and then changed it back to 1000ms, the issue might also go away if both tasks end up offset. The problem might return. At 500ms the signal to the FFAO will always be updated faster than the Module execution.
  
  I also think that if you set the macro cycle to say 800 ms, that would take care of the IO Output failure, but that would create a variable delay in the signal path as on one scan, the output is seen within 100 ms, but on the next it takes 500ms and the next it could be delayed by 300 ms or whatever. Using the 500ms as an even fraction of 1000 ms, the IO delay will be more consistent from module scan to scan.
  
  Worth a try.

  Andre Dicaire

  • Cancel