# OPC string tags and Ignition performance

**URL:** <https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [May 23, 2022, 11:31pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934 "2022-05-23T23:31:08Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Torsten\_Utsch](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Torsten\_Utsch](https://forum.inductiveautomation.com/u/Torsten_Utsch)\
**Post date:** [May 23, 2022, 11:31pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/1 "2022-05-23T23:31:08Z")

</div>

Hello,  
I’m currently working on my company’s Ignition standard template for upcoming projects. For triggering HMI alarms from the PLC, I’m trying to decide between:

1. Generating an alarm message in the PLC and displaying the message in Ignition directly
2. Programming a status word in the PLC and hardcoding the message in Ignition based on its value

I would prefer 1) but I’m wondering if Ignition would take longer to update a large number of String tags instead of Integers. Are there any implications to Ignition’s performance when reading String tags over OPC vs. Integers or Boolean tags?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [May 24, 2022, 12:30am UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/2 "2022-05-24T00:30:31Z")

</div>

Yes, definitely, and how much of an impact will further depend on the type of PLC it is.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [May 24, 2022, 12:50am UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/3 "2022-05-24T00:50:31Z")

</div>

I would stay away from #1. That was a nice way to do things if using FactoryTrash. You would give up alarm history. Alarms are a snap if using UDTs.

I recommend learning ignition and everything it can do and don’t get hung up on trying to do things the way you are used to.

---

<div class="post-metadata">

**Author:** ![Torsten\_Utsch](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Torsten\_Utsch](https://forum.inductiveautomation.com/u/Torsten_Utsch)\
**Post date:** [May 24, 2022, 3:24pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/4 "2022-05-24T15:24:00Z")

</div>

Thanks for the replies.

I’m mainly using Bosch Rexroth and Siemens S7-1500 PLCs, both as OPC servers with OPC connections in Ignition.

In any case, I’m planning to trigger the alarm in Ignition on a tag in a UDT and using Ignition’s alarm status table & alarm journal. I’m mostly wondering about the most optimal way to define the alarm message content for Ignition’s performance.

I’m currently using a Boolean tag in the Ignition UDT to trigger the alarm and a string tag for the alarm message content. Another method I consider is to use an Integer tag in an Ignition UDT for an alarm code from the PLC and a memory tag dataset with lookup for the alarm message. Does anyone have experience with this?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [May 24, 2022, 3:31pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/5 "2022-05-24T15:31:01Z")

</div>

If you have OPC UA connections to the PLCs and not driver connections then Strings don’t have as much overhead because we won’t be polling them - they’d be sent once when the subscription was made and then only again when they actually change.

---

<div class="post-metadata">

**Author:** ![jlandwerlen](https://avatars.discourse-cdn.com/v4/letter/j/bc8723/32.png) [@jlandwerlen](https://forum.inductiveautomation.com/u/jlandwerlen)\
**Post date:** [May 24, 2022, 4:50pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/6 "2022-05-24T16:50:22Z")

</div>

Consider using JSON tags if using PLCs with OPC UA servers.

---

<div class="post-metadata">

**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\
**Post date:** [May 24, 2022, 5:46pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/7 "2022-05-24T17:46:59Z")

</div>

I’m just going to lob in some philosophy. In my opinion:

- An alarm is _functional concern_ of your machine control (an alarm exists or doesn’t exist, and can be used to modify operations)

- An alarm message is _presentational concern_ of your machine control (its only value is to the operator of the machine)

Mixing up different concerns in your overall design makes for a system that is not as clean, and is harder to change or adapt to future changes. Which makes maintenance harder than it should be.

Thus I feel that the better architecture is to keep you concerns separated [1], so that your PLC is is only concerned with machine control and generating alarms, while your HMI system is only concerned with displaying information (such as alarm messages) to the operator in a human readable format.

So to me, creating numerical values in the PLC that indicate alarm conditions is the better design architecture.

As a reverse analogy it would be really, really bad design to put your machine control logic in your HMI, rather than in your PLC.

* * *

[1] Sometimes it is not possible, for example where your machine control and HMI system are one and the same device.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [May 24, 2022, 7:31pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/8 "2022-05-24T19:31:06Z")

</div>

> [@peter](#):
>
> So to me, creating numerical values in the PLC that indicate alarm conditions is the better design architecture

This contradicts your other statements, IMNSHO, since every machine I've ever dealt with could produce simultaneous alarms. Arrays of bits makes the machine control simple when multiple alarms exist. Leave presentation of those alarm bits to the HMI.

---

<div class="post-metadata">

**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\
**Post date:** [May 24, 2022, 7:36pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/9 "2022-05-24T19:36:01Z")

</div>

A bit still is a numerical value, it just happens to only have a few values:

- True
- False
- File\_Not\_Found

😃

And I didn’t mean a single numerical value to cover all alarm states, I was trying to differentiate between alarm messages and alarm states

---

<div class="post-metadata">

**Author:** ![andrews](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@andrews](https://forum.inductiveautomation.com/u/andrews)\
**Post date:** [May 24, 2022, 8:36pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/10 "2022-05-24T20:36:30Z")

</div>

FWIW dual-bit alarming is a great concept.

Meaning, a bit for the actual alarm staying active as the alarm is active. Which can leverage some control.

And a notification bit, which activates with the alarm and goes away via the operator acknowledging it. i.e. if the alarm is no longer active, the notification bit stays active till someone is aware.

However I don’t think a second notification bit is needed in the PLC when using Ignition. Ignition has great alarm functionality. And I think that is best used instead. Unless you have some concern about changing systems (or screens) and need that somewhere in the PLC, so it will always be there.

If you are concerned about creating a lot of alarms, there are some post on here regarding creating alarms via scripting. It’s not super easy, but from what I remember its super doable. That might be worth you digging into deeper.

---

<div class="post-metadata">

**Author:** ![Torsten\_Utsch](https://avatars.discourse-cdn.com/v4/letter/t/41988e/32.png) [@Torsten\_Utsch](https://forum.inductiveautomation.com/u/Torsten_Utsch)\
**Post date:** [May 25, 2022, 3:16pm UTC](https://forum.inductiveautomation.com/t/opc-string-tags-and-ignition-performance/59934/11 "2022-05-25T15:16:17Z")

</div>

Thanks for all the replies, that really helped!
