Alarms in UDTs - Binding Associated Data to Tags

#1

I have a fairly complex alarming scheme. We are using notification pipelines to page the appropriate department when a piece of machinery goes down. The operator has to select the downtime reason code, and I am using scripting in their ‘submit’ button to lookup the appropriate department to page w/ a SQL query, then writing that to a memory tag before the actual alarm gets triggered.

Inside the pipeline, I am using a script w/ system.tag.read() commands to read various bits of useful information to include in the message body for benefit of the people responding to the page. First I need to tell the pipeline what piece of equipment the page is regarding, then use that string to concatenate the proper tag path so I can read the other pieces of information.

I originally tried using binding in the Associated Data to pull the name of the press like this:
[.]…/…/Asset_Info/Asset_Tag
I found that this doesn’t work. I need to go into each alarm and manually direct it to the right tag within the UDT instance that contains it. This is kind of pain, because it involved overriding the alarm which causes it not to inherit any changes made to that alarm in the original UDT (an additional data point per se).

Is there some different syntax needed that I’m not seeing here?

0 Likes

#2

Is the Asset_Tag in the same UDT as the tag you are alarming on? Should work - this is something similar on a alarm property binding using an expression:

if({[.]Parameter - Alarm Pipeline Enabled},
{[.]Parameter - Alarm Pipeline},
“”)

I think there has been some issues with earlier versions of Ignition where the alarm properties sometimes wouldn’t update correctly, what version are you on?

0 Likes

#3

You should be using ../ to go up each level instead of 3 dots.

0 Likes

#4

Strange, this must be a function of the HTML formatting or something when submitting posts; there indeed are only two dots in my path. This is the actual path I am using: [.]../../Asset_Info/Asset_Tag

Sorry for the confusion.

0 Likes

#5

Yes, Asset_Tag is in the same UDT. I’m on v8.0.2

Got this figured out. I used the same exact path just in the expression tab instead of the ‘tag’ tab. I have no idea why the tag path wouldn’t have worked and an expression with the same thing would have. Might have found a bug here?

Another interesting item to note, when I went into a udt instance and browsed for the Asset_Tag in the same instance, it came up with this path: {[.]../Asset_Info/Asset_Tag} instead of this: {[.]../../Asset_Info/Asset_Tag} which I believe is correct.

Here is my udt structure, the alarm is in ‘DepartmentPageTrigger’
image

0 Likes

#6

This would be a 8.02 issue - I always forget the right syntax, but the problem was you couldn’t just pick a UDT tag to bind to - I think it was fixed in 8.0.3, or maybe 8.0.4. You’ll see a selector to select from your UDT tags after the update

1 Like

#7

That might be reason enough for me to upgrade; I have been going down into a udt instance navigating out and make the path there, then copy pasting back into the original UDT. What a pain!

0 Likes

#8

Update:

The feature that lets you browse for items in the same UDT is fantastic! This saves a ton of time!

0 Likes