Propagation of Alarm TAG configurations

Ignition Modules MQTT Modules
,
1

Hi,
Is there any way to propagate a TAG’s alarm settings via MQTT to the Engine side?

Transmitter side:

imagen
imagen910×642 46.5 KB

Engine side (alarm configuration was lost):

imagen
imagen896×525 45 KB

Regards, Andrés

2

Propagation of alarm config is not supported. However, propagation of alarm events is supported. See here for details: Alarm Event Propagation - MQTT Modules for Ignition 8.1 - Confluence

1 Like
3

Thanks for the answer Wes,

Do you know if it is planned to incorporate that functionality?

Regards, Andres

4

This was actually something we removed some time back. It was confusing to propagate alarm config and have two alarms fire on the two different systems. So, we explicitly removed this as an option. However, it can still be done manually. We’ve had customers use scripting to automate the configuration of alarms on the Engine side.

5

Ok, I understand your point.

My goal is to be able to configure alarms from both the engine and transmitter sides, but I don’t want to use additional TAGs. I’m currently solving this by creating an additional Document TAG for each TAG that has one or more alarms configured.

I imagine that on the engine side, alarms could be disabled so as not to trigger two events and only take the original event coming from the transmitter side.

Regards, Andres

6

This is how most people do it:

  • Configure the alarm on the Transmission side
  • Set up Transmission and Engine to allow alarm events to propagate via MQTT
  • Don’t configure an alarm on the Engine side

With this setup, there is only one alarm event. It is ‘shared’ between the Edge and Engine sides. If the alarm is cleared or acked at either side, the clear or ack is reflected at the other side.

7

Sure, that’s how I did it initially, but the problem is that I can’t change the alarm configuration (disable it or change the setpoint) from the Engine side. The only way to do it is from an EDGE Panel session, which is my use case. That’s why we’re now using document TAGs to send and receive alarm configurations to and from EDGE Panels.

Regards, Andrés

8

Ah I see. Could you create edge side ‘control tags’ that allow you to make the Edge side config changes you need? For example, at the Edge:

  • Create a String tag that can be used to hold a tag config
  • Create a ‘write config’ tag
    • On this tag, create a tag change script that writes the config from the other tag to the tag that needs to be updated.

If you include these tags in the scope of your Edge Node (or another ‘control node’), then you could perform the writes at the Engine side.

9

That’s exactly what I’m doing now. I created a memory-type TAG in document format on the transmitter side and inside it I put the alarm settings (enablement, setpoint, priority, etc.). I associated a script triggered by the change event of that TAG that changes the alarm settings in the desired OPC TAG. Since this document TAG is propagated via MQTT, it can be written and read from the Engine side. This works very well, and we haven’t had any issues so far. The problem is that it involves creating an additional TAG for each OPC TAG that has associated alarms, and that’s what I want to avoid since there are many TAGs.

Regards, Andrés

10

Why do you need a control tag per OPC tag? Could you use a tag that allows you to specify the path as well as the config so you only need one or a handful of control tags?

11

Yes, you’re right. I could use a single TAG that contains the settings for all the necessary alarms. It would be a bit more complex to manage, but it would reduce the TAG count.