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:
Generating an alarm message in the PLC and displaying the message in Ignition directly
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?
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?
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.
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.
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.
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.
