Expression Tag Quality not evaluating correctly - Possible Bug?


I have a simple boolean expression tag (Name: Idle) inside a UDT which evaluates the condition of multiple process tags within the same UDT to determine if the machine is 'Idle' or not. The process tags are coming from two separate machines, so if one of the machines is switched off approximately half of the tags in the 'Idle' expression will have 'Bad' quality, however the quality of Idle is still showing 'Good'.

If I reduce the number of tags referenced in the expression to ~5 or less (the exact number seems to change depending on the ratio of 'good' quality vs 'bad' quality tags in the expression) than the quality of 'Idle' is 'Bad' when one of the machines is switched off - which is my desired behaviour. However I need to evaluate ~20 tags in the expression and when I have them all together if the quality of at least one of those tags is good than the 'Idle' tag quality evaluates as good.

I can replicate this same behaviour outside of a UDT so I don't think it is that. I have tried splitting the expression up into two expression tags, ie 'Idle_Machine1" and "Idle_Machine2", so that all the tags in the individual expressions should have the same quality under normal circumstances - which works for the individual expression tags, but as soon as I create a third expression tag ie

Idle_Machine1 = True &&
Idle_Machine2 = True

Then the expression will still evaluate as quality of 'good' if Idle_Machine1 quality is 'Bad' and Idle_Machine2 quality is 'Good'.

Any ideas for a work around?

Try the isGood() expression function like this

isGood({[.]Bool 1}) &&
isGood({[.]Bool 2}) &&
isGood({[.]Bool 3}) &&
isGood({[.]Bool 4}) &&
isGood({[.]Bool 5}) &&
isGood({[.]Bool 6}) &&
isGood({[.]Bool 7}) &&
isGood({[.]Bool 8}) &&
isGood({[.]Bool 9}) &&
isGood({[.]Bool 10}) 
1 Like

Thanks for the suggestion dkhayes117.

If I do my expression like this than the 'value' of my tag is no longer giving me the idle status of the machine, but rather whether or not the tags of my machine have a 'good' quality - and the 'quality' value of this expression tag will always be good

What I'm trying to achieve is that the 'value' of my tag indicates if the machine is idle and ready to run:

{[.]../Process/Critical_Alarm} = "False" && //no active critical alarms
{[.]../Process/Ext1_BarrelZone03/CtrlState 1} = 6 && //Extruder Barrel zone is in 'Control_ON' state
{[.]../Process/Pell1_Dryer_Disconnect} = True && //Pelletizer Dryer disconnect switched ON

and I want the 'quality' of this tag to be 'bad' if any of the tags in my expression do not have a good quality. This works as expected provided I only have a couple of tags in my expression, once I get over a certain amount the 'quality' of this tag evaluates to 'good' even if some of the tags in the expression have a quality of 'bad'

It might be an overloaded expression that is taking too long to evaluate, I really don't know that much about tag expression backend. Or maybe one of the tags has a longer poll rate, so it takes longer for the change to propagate? I'm not really sure.

You might could break this up into 2 smaller tags, like 1 that checks to make sure all the associated tags are good using isGood and name it tagQuality. Then use another expression tag to run the expression based no the values you want to check. Then combine the two smaller expression into your final idle tag.

Thanks, I ended up doing just that - I have an 'Idle' tag with my original expression to get the machine idle status, another expression tag 'Idle_TagQualityGood' which evaluates true if all of the tags used in the 'Idle' expression have good quality (using the isGood()), and then in my final 'Idle_status' tag I have the following expression:


Needing to use a forceQuality code of '0' to represent 'Bad' threw me through a loop - I'm on 8.1.17 so supposedly I should be using the quality codes from here:

however for whatever reason I needed to use the codes referenced in the 7.9 manual:


forceQuality uses the legacy code values because it was introduced before the new quality codes. So if we changed how forceQuality works now, anyone's expression that relies on the 'old' values would suddenly have the wrong logic.

The modern alternative is qualifiedValue:
As in:
qualifiedValue({[.]../Process/Idle}, 0)
For an unspecified 'good' quality.

1 Like

Thanks PGriffith, that makes sense.. it would be nice for future users if the "quality codes" hyperlink in the "forceQuality" 8.1 documentation was fixed to take the reader to the legacy codes then instead of directing them to the new quality codes that don't work with that expression: