Hey guys,
I upgraded to 7.6 RC3 over the weekend and I’m still having a lingering issue with binary alarms activating when they shouldn’t and then never clearing. In the example below you can see from the logged journal entry that the alarm activated when false, which it shouldn’t do. The tag has been false, which should be a reset condition, but the alarm has been active for 2 days now.
Is the alarm mode Equal to 1 the correct way to do binary alarms? That’s how they were ported over in the upgrade from 7.5 so that’s how I left it. I’m not sure what other information would be helpful for this so if you need anything else let me know. Thanks!
Hi,
If you disable the tag driving the alarm, does the alarm go away?
Is this system redundant? Was there anything in particular that caused this alarm to go active, or did it just start that way and never go away?
Regards,
Ok, I disabled the tag and the alarm cleared. I re-enabled the tag and the alarm did not come back yet.
This is a redundant system, yes.
It’s very possible that the alarm tag actually went to true. Since it was a weekend the system PLC may have been powered down for maintenance. It was not active after I upgraded the server on Saturday morning, so it didn’t start that way. That alarm came in later.
Hey Colby,
I’m noticing this behavior on other types of alarms as well (above setpoint, below setpoint, etc…). The common factor seems to be having a non-zero value in the Active Delay parameter for the alarm. When the value drops below the setpoint it seems like it’s never stopping the delay timer. The alarm activates, even if it’s no longer above the setpoint and then stays active.
Ah, you’re right, that’s exactly what’s going on. Thanks for playing around with it more, we’ll get it fixed this morning before 7.6.1 goes out.
Regards,
Awesome, thanks! This was driving me crazy. 
