Expression Type casting requires cast from within UDT

Ignition Early Access
1

I have a setup where the customer wants to be able to plug in setpoint values to dynamically change values that trigger alarms. They also want to animate things on the screen based on these alarm conditions.

I made a UDT that looks like this:UDT%20Type%20Casting%20Bug

“Actual” is bound to the live PLC value.

“HighSP”, “LowSP” and “Compliance Level” are adjustable setpoints which indirectly set alarm conditions.

“Low Alarm”, "High Alarm and “Compliance Alarm” are boolean flags that use expressions to be flagged if we are in their respective alarm condition. I’m doing Perspective transforms off these bits to change how the data point is styled based on alarm conditions.

All that said, the expressions that determine my bit states are sometimes (semi-inconsistent) requiring me to cast doubles to doubles before comparing them. If I don’t cast to double I am seeing some instances of my UDT throw expression errors while others do not. It’s weird.

2

What expression functions are you using, and are you on the latest nightly build? Within the last week or so, a change was merged in that should make expression functions always attempt to coerce (and if they can’t, diagnostics/the quality value returned should have more information).

3

I’m just using indirect binds to the other memory tags on the UDT. I’m wondering if I did something wrong when making my UDT because I tried to copy/paste the definition into here and it didn’t get the sub tags.

High Alarm expression looks like this:
toDouble({[.]Actual}) > toDouble({[.]HighSP})

If I take out the “toDouble” it will throw errors on some instances but not all.

If I select all the sub tags and copy it looks like this:
{“type”:“tags”,“payload”:{“tags”:[{“tagPath”:"[default]types/Value LHCS",“objectType”:“UdtType”,“subType”:"",“hasChildren”:true,“dataType”:“String”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/Actual",“objectType”:“AtomicTag”,“subType”:“expr”,“hasChildren”:false,“dataType”:“Float8”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/Compliance Alarm",“objectType”:“AtomicTag”,“subType”:“expr”,“hasChildren”:false,“dataType”:“Boolean”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/Compliance Level",“objectType”:“AtomicTag”,“subType”:“memory”,“hasChildren”:false,“dataType”:“Float8”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/High Alarm",“objectType”:“AtomicTag”,“subType”:“expr”,“hasChildren”:false,“dataType”:“Boolean”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/HighSP",“objectType”:“AtomicTag”,“subType”:“memory”,“hasChildren”:false,“dataType”:“Float8”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/Low Alarm",“objectType”:“AtomicTag”,“subType”:“expr”,“hasChildren”:false,“dataType”:“Boolean”,“attributes”:[]},{“tagPath”:"[default]types/Value LHCS/LowSP",“objectType”:“AtomicTag”,“subType”:“memory”,“hasChildren”:false,“dataType”:“Float8”,“attributes”:[]}]}}

4

Disregard the weirdness on the defined alarms. I had a previous version of the UDT that was watching for values to exceed the dynamic values with an expression. When I added the booleans to track that condition it was no longer necessary to have an expression on the alarm condition but I forgot to remove it.

The issue occurs in the expressions to calculate the value of the alarm bits which I use for animations.

Sorry for any confusion.

5

Hi @Steve_Laubach,

Apologies for the delay here - are you still seeing this issue?

6

I think it’s fixed. I have to go through all my alarms thoroughly to make sure they’re all there but I have since created instances of UDT and the alarms appeared in my logging table.

1 Like