# Ignition 7.9.13 Alarm Structure, Limitations and Scalability

**URL:** <https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231>\
**Category:** Ignition\
**Tags:** ignition79\
**Created:** [October 31, 2023, 2:02pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231 "2023-10-31T14:02:09Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![timothy\_moan](https://avatars.discourse-cdn.com/v4/letter/t/ebca7d/32.png) [@timothy\_moan](https://forum.inductiveautomation.com/u/timothy_moan)\
**Post date:** [October 31, 2023, 2:02pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231/1 "2023-10-31T14:02:09Z")

</div>

Hello,

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.

UDT Alarm Configuration:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/d/2d8cc2b4af78e8d95365b1a40f40b42a140dd33a.png)

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:

```auto
//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"
)

```

Here is an example of the dataset tag.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/2/029ba7df3efd5e493574679aa391a859325cea38.png)

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?

---

<div class="post-metadata">

**Author:** ![kyler.kamyszek](https://avatars.discourse-cdn.com/v4/letter/k/a4c791/32.png) [@kyler.kamyszek](https://forum.inductiveautomation.com/u/kyler.kamyszek)\
**Post date:** [October 31, 2023, 7:28pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231/2 "2023-10-31T19:28:03Z")

</div>

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.

> [@Efficient way to import 500+ alarms into ignition from Allen Bradly plc](https://forum.inductiveautomation.com/t/efficient-way-to-import-500-alarms-into-ignition-from-allen-bradly-plc/72445/9):
>
> HMI alarms list from FactoryTalk View ME Studio. From what I understand, Ignition's OPC Server, and any other non-Rockwell OPC server, doesn't support Rockwell's Alarms and Events feature (at their current states).

---

<div class="post-metadata">

**Author:** ![timothy\_moan](https://avatars.discourse-cdn.com/v4/letter/t/ebca7d/32.png) [@timothy\_moan](https://forum.inductiveautomation.com/u/timothy_moan)\
**Post date:** [October 31, 2023, 7:45pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231/3 "2023-10-31T19:45:46Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![kyler.kamyszek](https://avatars.discourse-cdn.com/v4/letter/k/a4c791/32.png) [@kyler.kamyszek](https://forum.inductiveautomation.com/u/kyler.kamyszek)\
**Post date:** [October 31, 2023, 7:51pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231/4 "2023-10-31T19:51:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![timothy\_moan](https://avatars.discourse-cdn.com/v4/letter/t/ebca7d/32.png) [@timothy\_moan](https://forum.inductiveautomation.com/u/timothy_moan)\
**Post date:** [October 31, 2023, 8:08pm UTC](https://forum.inductiveautomation.com/t/ignition-7-9-13-alarm-structure-limitations-and-scalability/81231/5 "2023-10-31T20:08:49Z")

</div>

No webDev module, I'll proto a script for importing and see the team's opinion on implementation.