With the raft of impressive new alerting features in 7.6 I was hoping that there would be some variations on the Any Change Alert i.e. separate Change to On and Change to Off alerts, allowing different alert names(messages) for rising and falling edges, but always entering the list as a cleared alarm(like your Any Change Alert), so once acked they would exit the list.
Much of our work is involves the monitoring of large power systems and whilst the change of a breaker position is very important it could legitimately be open or closed depending on how the site is configured at the time, so any change should enter the list but once accepted by a supervisor should exit the list to enable the daily operator to easily view any unscheduled events.
Currently we have a workaround script that splits the alert name into two parts on a special char and filters the display according the actual digital tag state; looking at 7.6 I am not sure we could intercept the display data anymore, so we would actually loose functionality.
Hope fully I have missed something here and there is some way of achieving this, if not I doubt this is a difficult request. 
Hi,
I think I understand what you’re requesting, I’m just not quite sure I understand how you’re currently accomplishing it. What does your current alarm setup look like? When you say that you can’t intercept the data anymore, do you mean because you’re querying the status from the system, and not a db table?
These are boolean tags, correct? How about this:
- Create an alarm set to “any change” mode.
- Bind the display path to an expression:
concat("Breaker ", if(toBoolean({Value}), "closed", "open"))This will give the alarm a different display path depending on the value, and will fire events that are already cleared any time the value changes.
What do you think?
Our existing workaround script retrieves the alert history using your system.alert.queryAlertHistory() function and then checks the field for each row, if the state name contents are of the form ?Open?Close or ?Stopped?Running I then split the field on ? and choose the correct state name according to the digital value of the alert, the modified dataset is then displayed in a regular table component.
I can email login details for our demo if you would like to see this in operation.
Although your suggestion should work, I think the and fields really should be separate both for appearance and ease of use i.e. searching/filtering
I assume your new alert display components gathers the alert data direct from the alert system and there is no opportunity to intercept and filter/modify the state name field as we do with V7.5
The most practical solution from our perspective is a dedicated Change to On alert and a Change to Off alert, but as most of your existing alert type are generic to both digital and analog, maybe this would be better implemented as alert on rising value and alert on falling value with adjustable levels and dead bands exactly as your existing Any Change alert?
This would be a seriously useful feature for us, historically we had this functionality in Rockwell’s ancient RSView32 and whilst Ignition pretty much blows RSView32 into the weeds on every other front, this one has not been easy to bridge.
Our existing workaround script retrieves the alert history using your system.alert.queryAlertHistory() function and then checks the field for each row, if the state name contents are of the form ?Open?Close or ?Stopped?Running I then split the field on ? and choose the correct state name according to the digital value of the alert, the modified dataset is then displayed in a regular table component.
I can email login details for our demo if you would like to see this in operation.
Although your suggestion should work, I think the and fields really should be separate both for appearance and ease of use i.e. searching/filtering
I assume your new alert display components gathers the alert data direct from the alert system and there is no opportunity to intercept and filter/modify the state name field as we do with V7.5
The most practical solution from our perspective is a dedicated Change to On alert and a Change to Off alert, but as most of your existing alert type are generic to both digital and analog, maybe this would be better implemented as alert on rising value and alert on falling value with adjustable levels and dead bands exactly as your existing Any Change alert?
This would be a seriously useful feature for us, historically we had this functionality in Rockwell’s ancient RSView32 and whilst Ignition pretty much blows RSView32 into the weeds on every other front, this one has not been easy to bridge.
I suggested using Display Path because the new components tend to show that if possible, and then fall back to the alarm name that isn’t defined.
The method I suggested seems pretty clean to me, I’m not sure what your concern with searching is. You can search based on display path (and in fact, the “search” box on the journal component includes both source and display path). However, it’s also worth noting that with the new alarm system, you can create your own fields on alarms (“associated data”). You could make one called “state”, and bind it to something like what I suggested for display path. The scripting functions like you search based on properties, so it’s easy enough to say “give me everything where state=‘open’”. The journal component doesn’t have support for this right now, but it could be useful in other contexts.
There’s another possible way of doing this (though I tested it, and it doesn’t quite work in the current beta, but has been fixed for the next): The inside/outside range modes also have an “any change” mode, that only applies when the value in inside (or outside) the range. You could create two alarms using the inside range mode, going from 0->0 inclusive, and 1->1 inclusive, with “any change” turned on. This would fire any change style events, but only on the specific value.
Anyhow, at the end of the day, it’s easy enough for us to add conditions (and one of the features on the road map is the ability for users to define their own conditions in python), so specific modes could be added.
Regards,
I think I now understand your original suggestion, however we already use the DisplayPath field as a more human readable description of the plant item posting the alert and whilst we could append the state name to the end of this , I feel it should have its own column.
The other two suggestions look quite promising and I will give them a try as soon as the next beta is released.
The ability to define our own alert conditions in python looks good, any idea when this will be available?
Thank you for your help.The custom alarm rules will likely be in 7.7, just because we like to avoid adding features of any kind of substance in the incremental (3rd number) releases.
Regards,