UDT updated with Bad OPC Item Path not triggering pipelines

Ignition
1

I was testing the Alarm Pipelines in Ignition 7.6 and when the “Bad Quality” alarms would trigger the active pipeline. I needed to test my filtering expression for “Bad Quality” vs “Low Setpoint” etc, but I ran into a problem where the “Bad Quality” status for the SQLTag did not trigger the active pipeline.

For testing, I created a UDT to connect to the Refrigeration simulator device. I created two instances of the UDT which was successfully triggering “HIGH” alarms and “LOW” alarms and their associated active pipelines. (These alarms are visible in the Alarm Summary table.) I edited my UDT OPC Item path for the SQLTag to an invalid path. Unfortunately, the active pipelines associated with the “BAD QUALITY” alarm did not trigger. (These “BAD QUALITY” alarms are also visible in the Alarm Summary table.)

I was able to complete my testing by setting the OPC path to the correct path and then changing the name of the configured device in Ignition’s OPC-UA server. As soon as the change was made, my “BAD QUALITY” active pipeline was triggered.

I thought this might be by design (propagated changes of the UDT to its instances could be seen as a “first-event” trigger and initially ignored) but in my mind an item that shows up in the Alarm Summary table with an associated active pipeline should always trigger the pipeline.

So, should UDT changes propagated to its instances cause BAD QUALITY alarms to trigger their associated active pipelines?

Ignition Version 7.6.4 (b2013112117)
Java Version Oracle Corporation 1.7.0_21

2

Hi,

I think your intuition was correct, and what was happening was that the events caused by the edit were considered “initial events”, and weren’t sent. This behavior is controlled by the setting “Notify Initial Events”, under Alarming>General in the gateway config.

This situation, of trying to test alarms by modifying a tag’s configuration, trips up a lot of people. The biggest thing this system is trying to avoid is sending out a ton of alarm notifications when the system starts up. There is already a mechanism that tries to detect events that previously existed on shutdown, so setting the above mentioned option to “true” could work fine for you, but on unexpected shutdowns you would end up with repeat notifications. That’s why there’s an option, because people have wanted it both ways over the years.

There’s probably room for improving the logic a bit, though, so that newly created alarms get sent, or tags that become active directly as a result of modification.

Regards,