Emerson Exchange 365

• Not Answered

How do I stop the AT block from flooding event chronicle?

We are running DeltaV v13.3.1 and are using the new AT block. This is a great tool to "interlock" PID blocks and provide visibility to the operator as to what is happening and allows each interlock condition to be bypassed.

However, for some tracking conditions, our tracking value is not a constant value, but changes, by design. For example, we want to track a PID blocks output to match another valve output. Imagine my surprise when I open up PHV and discover that the Event Chronicle is now riddled with messages every second of the day the whole time the AT block is tracking and reporting that the output is changing.

How do I make the AT block stop reporting to the event chronicle with every little output change?

Why is this "feature" not configurable?

Thank-you.

KeithStThomas

• 12 Oct 2022 11:31 PM
• Cancel

6 Replies

• Matt Stoner

  

  • 13 Oct 2022 12:23 AM

  Can you give more information on the control scheme you are needing/wanting? It looks like you are trying to use tracking instead of maybe using selection or back calculation statuses for override or not selected control.
  
  There is no method to turn off the logging of the events except for having the FDBK_IN value into the AT block be >= OUT - OUT_HYS AND <= the OUT + OUT_HYS at the time the condition comes true. This essential is only logging if the block thinks that it will actually be changing the final output. It will also log when all conditions have cleared as well that haa no control.
  
  Take a look at Books Online for the block but I think there is probably better configuration method(s) for what you want your control scheme to do than using AT for tracking.

  • Cancel
• KeithStThomas

  

  • 13 Oct 2022 5:18 PM

  In reply to Matt Stoner:

  

  We are using the AT block to track the valve closed if the steam flow is below a minimum threshold. Also, the operator has the ability to bypass the DCS and control the valve with an external single loop controller at his panel. When the external controller is in control, we readback the analog output signal to the valve to track the PID1 block to match for bumpless transfer.

  The AT block logs when the condition goes true, and provides visibility to the operator when the PID is being tracked. We like these features of the AT block. We don't like that it reports continuously for the slightest output change, even if I set the OUT_HYS to a value other than 0, e.g. 999.

  Another oddity is the output value reported in the Event Chronicle shows up as Chinese characters, while the rest of the message is English. This only happens to the AT1 block, and is happening on our Production and Development systems.

  Thanks.

  • Cancel
• Matt Stoner

  

  • 15 Oct 2022 7:16 AM

  In reply to KeithStThomas:

  Sorry for delay...working night shift at customer site.
  
  I suggest logging a call with GSC as appears there is a couple issues that look to be incorrect if it is logging within the OUT_HYS range and the Chinese characters being used.

  • Cancel
• Pat Grider

  

  • 17 Oct 2022 2:33 AM

  I think Emerson's intended use for the AT function block is the case where the PID or AO TRK_IN_D and TRK_VAL is being used to produce an interlock-like effect, and the T_VALn parameters are expected to be constant.
  
  Regardless, I can confirm the same logging behavior in 14.3.1. In the scenario where the AT needs to track a *moving* value this logging behavior makes it pretty much unusable.
  
  From Books Online:
  "An event chronicle entry is added when any condition becomes true that changes the tracking analog output"
  
  From a plain reading, the log entry should occur if any condition BECOMES true (positive edge trigger) AND the AT output value changes.
  
  But that's not what happens. A log entry occurs if any condition IS true (no positive edge trigger required) AND the AT output value changes.
  
  I can't believe Emerson intended to fill the chronicle up with spam so they probably just failed to test the behavior for moving T_VALn values.
  
  Hopefully as Matt suggested there's a different way to achieve your desired outcome, it sounds tailor-made for the PID block's ROUT mode. Maybe the YOKO_OUT parameter could be wired to PID1/ROUT_IN & use CND and ACT blocks to detect the "remote tracking" condition and change the PID mode to ROUT & back as needed. It's good that you've got a development system handy.

  • Cancel
• Mark Bendele

  

  • 18 Oct 2022 8:02 PM

  In reply to Pat Grider:

  You can put a transfer block between the AT and the PID to pass YOKO_OUT to PID1/TRK_VAL when AT1/T_OUT_D1 is true; otherwise, AT1/OUT passes through. You can show T_OUT_D1 as an output on the AT block to connect to XFR1/SELECT. I have never done that, but I have put a ramp block between the AT and the PID.

  • Cancel
• KeithStThomas

  

  • 15 Dec 2022 11:00 PM

  In reply to Matt Stoner:

  I am disappointed that GSCs response is the AT1 block ignores OUT_HYS and reports any output change to EC by design. Also, the Chinese characters are a known issue with v13.3.1 but there are no more hotfixes for this version, so the fix is to upgrade to v14.

  • Cancel