Since we’ve upgraded our application from 7.9.3 to 7.9.4, alarm display path displayed in alarm status are not OK.
We use alam display path calculated with expression:
concat("{codeGTC}"," | ","{codeGMAO}"," | ","{designationInstanceEqt}")
codeGTC and codeGMAO and designationInstanceEqt are UDT String parameter
Upgrade at 2017/08/24.
Old alarm in 7.9.3 are OK, new one in 7.9.4 are NOK
Perhaps it is related to :
Ignition 7.9.4 Changelog mention :
Fixed - UDT parameter references in alarms are incorrectly replaced in memory when instances are
created, potentially leading to incorrect instance creation (issue introduced in 7.9.4
beta)
Are those variables being accessed via Associated Data properties, or are they direct references to the UDT parameters? Would it be possible for you to send us a tag export of the UDT in question?
We’re looking into it. Looks like something is somehow changing parameter names to include “{ }” around them on the UDT definitions, but it’s not very reproducible. I’m sure we’ll track it down shortly…
Yes sure.
I will post tomorrow UDT and tags xml export.
@James.Lorenz, @Colby.Clegg
Example of udt and instance to try to reproduce this issue
tags.xml (1.2 KB)
udt_.xml (24.6 KB)
Hey, I found yesterday also some issues with parameters in UDT.
To reproduce ::
- Create a UDT
- Create a parameter long
- Create a first param string1 with value
- Create a second param string2 with value
- Create a tag expression in UDT = to param long
- Create a tag expression in UDT = to param string1
- Create a tag expression in UDT = to param string2
3rd tag expression (and also 2nd some time) will fail to calculate.
Which version of Ignition were you using? Also, for the string parameter references in the expression, are you using quotes? i.e. “{param}”
7.9.3 (b2017060210)
And I tried everything 
{mystring}
‘mystring’
“mystring”
there is a tricky bug there first one is working in some cases, but never the second
One thing to be careful of when editing UDT’s in the Designer is NULL values… I think some of this issue might have been addressed in 7.9.4, but I’d still look out for it. For example, if you create a new data type, and add a tag to it and change [from Integer] to Boolean and save, you’ll have instances of that type (along with the type itself) have NULL values for that tag. This is especially tricky for Boolean data types since they don’t show NULL in the designer, only a check box. You have to “wiggle” the value (change to true, apply, change back to false, apply, for example) to ensure that instances start with a correct value. This might be something to look at when you’re having things fail to resolve (which can happen due to null-coalescing) properly. Here is an image showing the data type export and what to look out for:
Again, this might not be your issue, but I’ve struggled in debug on a few things until I discovered this behavior.
1 Like
An updated version 7.9.4 is now out, which solves the issue raised by Lionel in the original post.
