I am working on defining a structure for Alarm Management in Ignition but want to ensure the method does not lead to issues with scalability or load as the system expands.
My goal is to build a UDT containing 32 bits of alarms stored as an INT. Each bit of the INT will represent one fault that is reading a DINT internal to an Allen Bradley PLC.
Alarm Label, Priority, and display path are defined through an expression binding that references a dataset tag 1 layer above the UDT. I pull the appropriate property through a lookup.
Example logic for label:
//Lookup alarm label from table provided two layers up from UDT.
//Table Name: Alarm_Table stored as dataset
//Joins Source PLC, Base Tag, and Bit Position to build lookup value
lookup(
//Table Name
{[.]../../Alarm_Table},
//Build the base tag for PLC as concat, use alarm name to pull bit position.
concat("[","{sourcePLC}","]","{baseTag}",".",substring({name},4)),
//If no Alarm found return message to alert Engineering
"Undefined Alarm, please contact Engineering.",
//Lookup Column, tagpath
"tagPath",
//Output Column, label
"label"
)
I’ve prototyped 32 bits but am concerned how the system will scale as the dataset grows and additional UDT instances are added. If I transition all faults to this structure I will have ~1k rows per dataset and 11 datasets total. Any limitations I should be aware of or better structure recommendations?
I feel that the dataset tag is a little redundant. I know where you're coming from, you want to avoid manually adding in the fault messages into the tags. I don't see much of a performance hit on this method though. Just make sure your scan classes are reasonable.
Look into using tag import for your tags. Keep a master list in a spreadsheet and make an export tool/script to output xml to put in your tags. Then just import all of your tags, even if just one alarm changes or is added.
I had considered that path, I've recently developed a script to convert XML to XLSX for FactoryTalk exports but that was for limited use. The main challenge with a Master List is making sure both current and future team members are aware of the list's location and understand how to execute the required scripts. Ideally, I wanted the logic to be 'self-documenting', allowing for easy retrieval of all faults without the need for secondary systems. I'll consider your suggestion, thank you for the advice!
My implementation could be taken one more step and put directly into Ignition. I just haven't really needed it yet. If you have webDev module, you could have the script directly access xlsx and pull in the alarms or upload the xlsx to a view and run the script.
