Forgive me if this has already been answered, but I couldn’t find anything in the forums or manual on this.
We’re running into a little bit of a headache with the UDT’s that we have configured. Whenever we make edits to the UDT it causes any alarms configured in the UDT to re-evaluate and re-send any alarm notifications that were already active. It makes sense why it happens, but I was wondering (and hoping) if there is a way that we can prevent alarms - that were active prior to the update - from creating a new alarm event in the journal and also prevent them from resending the alarm notification? We have quite a few instances of this particular UDT so it can create quite the barrage of notifications and new alarm events in the journal.
Thanks in advance!
-Will
This is exactly why the Notify Initial Events flag exists (and defaults to false)
Thanks Paul. I double checked that setting in the gateway, and it is indeed still set to false. Could it be the expression bindings we have? On the alarm setpoint and display path property we have some expression bindings that reference other tags in the UDT. Not sure if they might be switching to None or Stale briefly when the edit is made causing it to “get by” the initial notify flag check? I’ll also add that all of the tags in the UDT are either memory tags, expression tags, or SQL tags. There are no OPC tags of any sort in this project.
Thanks again,
-Will
Just wanted to add that a number of the expression tags in the UDT - that are referenced in those two alarm properties bindings - use the runScript() binding expression. Not sure if that can cause issues.
seeing similar behavior here. No runscripts, but lots of expressions/derived tags to be evaluated. Did you ever find a solution?