Bidirectional Tag Property Read/Write in Tag Binding

Ignition
,
1

Hello,

I have an interface that I'm building that is meant to allow authorized users to add / delete / configure alarms on tags.

image
image1148×643 20.3 KB

Each of the label_value view instances (the view with the label and the numeric entry field / dropdown / text entry field) has a tag property as a "path" parameter in the following format:

[default]{area}/{machine}/{metric}/Alarms/{alarm name}

This "label_value" view encapsulates another view, which contains the label and the value. There is a "value" Input/Output parameter on this view, which represents the alarm property's value:

image
image948×514 36.9 KB

The binding on the "value" parameter is a bidirectional tag binding. It utilizes that path of the alarm (in the format previously specified).

The issue I'm experiencing is that writing to the "value" parameter does not write back to the tag alarm property as expected. Is this a known issue? Can bidirectional tag bindings not be used to write to individual tag properties besides the tag's value?

The value changes momentarily when I modify the value in the input field of the label_value view, but it quickly changes back to whatever the tag alarm property is. Changes to the input field do not appear in the tag properties when monitoring from the tag browser.

I'm aware that I could use system.tag.configure() to achieve the same result, but I'd like for this to work using a bidirectional tag binding, if possible.

EDIT:
I noticed that my designer wasn't in read/write mode. After switching to read/write mode and attempting to change a tag property via my view, I received the following error:
image

I'm assuming that this means that I can't modify tag properties with a bidirectional tag binding.

Thanks in advance for any help.

2

You can modify tag properties with bidirectional bindings for things like [default]SomeTag.enabled or historyEnabled for example.

I believe you will need to leverage the system.tag.configure function. There is an example of configuring alarms in the docs I linked. I imagine this is due to how the TagProvider handles alarms as they are slightly different than just your normal tag properties since they have their own classes and interfaces on the java side.

3

You can modify tag properties, but alarms under the hood are a bit "weird".

As far as I know, the essential underlying disconnect is because alarms are treated as one property by the rest of the tag system. So you can "write" to SomeTag.Alarms, but you have to replace the entire alarm configuration, which could include many alarms. system.tag.configure is the approach if you want to do a more surgical edit.

1 Like