General Question on Alarm Hierarchy in 7.6

We run a hub and spoke configuration (at the moment) between three physical sites. When a broadband connection goes down even briefly, all the alarms at that site tend to flood and that makes it difficult to spot the one that says the broadband connection is down.

I tried constructing a simple hierarchy of expression and alarm tags. It almost works, then I ran into the sticky alarm bug The configuration goes something like this:

  1. Is any device at the site reporting?
  2. If not, raise a connection alarm.
  3. If there’s no connection alarm, is {[~]wuteveh/Diagnostics/Is Connected} true?
  4. If the broadband is valid and the device is connected, check the quality of a canary tag.

In practice I’ve found the 4th step is necessary because sometimes Ignition won’t show a problem with a device but the device won’t be reporting any data either. A gateway restart tends to fix this problem.

Anyway the question is; is this a good approach or is there a better recommended practice to address this kind of alarm flood problem?

Thanks, C


Yes, I think you’re on the right path. You’re describing various alarms, but to avoid flooding, you’ll need to probably create an expression tag that defines your “normal operating condition” (connection up, device good), and then bind the “enabled” property of your other alarms to that.

The bug you referenced in that thread was fixed a while ago, so if you have something similar going on, we should try to troubleshoot it fresh. However, I’d recommend upgrading to the recently released 7.6.3 version first, as there were a few bookkeeping issues fixed there, I believe.