So far, all of our alarms are run off a plc tags (the plc handles all the logic) so we only had to configure an alarm on that tag. However, now we would like to alarm based off battery voltages, so when it goes below a certain setpoint, it sends out an alarm.
The problem is since battery voltages constantly go up and down, it goes below and above and back below the setpoint, triggering the alarm many times on that one instance throughout the day. We would just like one alarm in 24 hours for each tag that's triggered. We have a UDT definition where this battery voltage tag is, and thousands of device tags that use it. I just got into working with the Alarm block consolidation option, but doesn't work the way I was hoping (it suppresses all instances and not just each own).
So this got me into thinking about putting in a script block in the pipeline and have looked into using the system.alarm.queryStatus to check if an alarm was in there in the last 24 hours based on source and such, but some of those go out of the alarm status table to assuming the journal. I guess I could query the journal as well, but have read that these can be inefficient and tax performance. I can filter specifically just the source path so it should only bring back a few dozen results at most which may help. Or should I do a query to our alarm database, so making a SQL query? Any better approaches that I may be missing and not getting overly complicated?
You could correct the alarm behavior by adding some logic to your PLC that latches a bool if your battery voltage is out of range. Then, use the bool to trigger your Ignition alarm instead of the live battery values. The PLC could then unlatch the bool once every 24 hours if the alarm condition is no longer present.
Within the PLC itself, it would also be possible to use delay ons and delay offs to moderate the alarm triggering and releasing to prevent premature triggering and clearing.
2 Likes
Going the PLC route would be ideal, but we would have to change hundreds of PLCs.
I did get a work around. I'll monitor to see the performance impact.
In the pipeline, I created a script block before the notification block that performs a prep query to see if the alarm has registered in the alarm data table, conditional on source, eventtime has not been in their within 24 hours and not equal to the eventtime that just occurred (I believe this is needed since it might write the alarm to the table before the script evaluates it). If the length of this result is greater than 0, then cancel the pipeline notification.
After thinking about this, a probably more efficient way of doing this aside from going the PLC route, would be to create a custom tag property on the battery voltage tag holding the alarm latch time stamp. A tag change script, using the Alarm Active event, would check this value and compare it to see if it's within the timeframe set. If over the time frame, it writes the current time in the custom tag property otherwise it leaves the current value.
Then, whether to send the alarm out or not, this can be done in either the pipeline script block to check the custom property time or on the configured alarm on the tag itself using an expression binding on "Enabled" or "ActivePipeline" to be blank if it's still within the timeframe. Though this needs to be tested and possibly adjusted to prevent race conditions.