I am developing dashboards for robot condition based monitoring. One major feature I need to implement is both the ability to real-time alarm end-users (through use of various components, like a flashing light, or simple text, but this isn’t my issue) and the ability to view all alarm history in an alarm table.
The problem is that each robot (which is connected on the gateway via OPC UA) is modeled as a UDT, with one notable “Alarm” tag that is an array 100 elements long. When a robot receives an alarm it will push the name of the alarm to the first open element, I believe in behavior similar to a stack.
I need to somehow translate this alarm array into a working alarm history and have the option to display any currently active alarms (currently active alarms are any names that are in the array, they clear and pop themselves when the robot doesn’t have that alarm anymore) with corresponding timestamps and status functionality. It would also be nice to customize names and priority levels as seen in the alarm tables.
I looked into adding alarms in the UDT for “any change” but there is no way to then parse out which active alarms are in the array and use them for my purposes. Thanks for the help!
Easiest option is probably a gateway tag change script, or a change script on the tag, that reads the array when it changes (or a timer, not sure how the change detection works with an array) and writes to some kind of UDT made of memory tags with the relevant alarms on them.
Are ignition alarms custom objects, like each alarm is a package of info - timestamp, name, priority, etc?
I understand scripting it all into some custom data structure to keep track of everything, but then how does that work with using the built in alarm features such as the alarm table. Can I format my data in some way that it is all compatible with the table and things like acknowledging, clearing, shelving?
Do you know what all the possible alarms for this system are that you would want to display? If you do I would create a memory tag for each and configure an alarm on these you would trigger.
The alarms are custom objects that include other information like display path, and other meta information, plus if you’re using an alarm journal extra information is stored in this relevant for each alarm instance (like user acknowledge time etc).
I guess you could create an alarm which you keep changing with new values. But I don’t know how this would mess up alarm journal and other features. Say the order switches a lot when alarms clear
I have no personal knowledge of what names could show up in the array. I have just been tasked with dealing with them so I need a way to dynamically show any active alarms and be able to put the name from the array alongside the timestamp it showed up and have statuses.
One thing to note is that the alarm array is historized “on change” to a postgres db (so anytime any element changes, whether somethin goes null and other alarms move up, or a new name is added, I believe all 100 elements get flashed to the db with a timestamp). There may be a way to script something so that it looks back for timestamps and values? Do you know how to create an alarm object? I could look into querying for any non-null array elements and try to structure those into the object that could be used in alarm tables
If all you need to do is write it to an alarm status table, and another system is doing the storage. A method I’ve used before is just changing the text rather manually. You can have a few memory tags in a UDT for each element:
A memory tag with the alarm configured (maybe triggered on a bool), this alarm will have its label, dislpay path, etc. as an expression linked to the other memory tags
Use memory tags to store the label and display path, and other values
When an alarm is triggered, use a script to write in what you want on the various memory tags, label, path etc. And then trigger the alarm on that main memory tag. This should display fine, though you may need to test what happens if you were to change these values when it is still active.
I’ve done this before when a TCP-IP connection (also to a robot) send an error message back, so 1 UDT worked well enough, and I didn’t have to worry about an array and what happens when the values changes around. But the principle should be the same.
I like the idea of having individual alarms configured. If you can’t get a list of the alarms that are programmed in the robot, then maybe you could add them via script when new ones are discovered by using system.tag.configure? If it exists, just turn it on. This would need to be outside of a UDT though since you can't add tags into a UDT instance.
I don't know how you handle the priority if youre not sent these
Also a good idea, as you can store some alarm history more easily. Just need to be careful that the alarm message doesn’t include any timestamps or unique information and if it does that your script parses this right. Very easy way to check it in a months time and find a million configured tags
It looks like your main challenge is turning a raw alarm array into a fully functional alarm system with history, timestamps, priorities, and active status, while keeping it compatible with Ignition’s alarm table features. A solid approach would be to use a tag change or gateway script to map array entries into memory tags representing real alarms. I would appreciate if you kindly share a short video or screenshots through a sharingplatform(idk if the forum allows or not) to show the array behavior and active alarms in real time.
That is the objective, correct. I definitely need to do some sort of transformation from the array to real alarms, the how is what I’m working on.
I was about to get what you asked for but unfortunately, all of my test robots are disabled right now so I am not getting any data over OPC UA. It is unclear when they will be enabled again so this project may be at a standstill, but I think I will look into everyone’s scripting suggestions with maybe a test array or something of the sort.
