[BUG-13866] Expression isAlarmActive : Invalid relative tag path

@awalker, can you fill a ticket for this:

Ignition 8.0.2-rc1
Note : the same UDT and expression work fine in Ignition 7.9.10.

Error for an expression tag inside an UDT with isAlarmActive("[.]…/TM/ETAT_ALIM_1")

Quality Diagnostics	Invalid relative tag path '[.]../TM/ETAT_ALIM_1'. No enclosing tag could be found.	WARN

Hi @mazeyrat,

I had someone look at this and it looks the same as an issue we are tracking already. I’ve linked the ticket number above and will let you know when its been fixed.

This issue was fixed in the 8.0.4 Nightly build that was uploaded today (7/23).

Was there a nightly released since July 18th with this fix? I seem to be having the same error on the isAlarmActiveFiltered using a wildcard for the tag path and we downloaded a nightly on August 1st. What’s weird is the website says the last nightly was July 18th but our modules show August 1st.


The “release date” on our website is inaccurate, for a variety of technical reasons not worth getting into - the build date on the modules is accurate.

The issue should be fixed in any 8.0.4 nightly from within the last two weeks, so if you’re still encountering it it may be a different issue or a regression.

Hi apgliber,

Have you tried modifying the Execution Mode for all your tags including UDT’s to Tag group?. That may help with the issue especially when you are upgrading from 7.9.

Thanks,
Anthony

I run some test with Ignition 8.0.5 final and I still have the issue with isAlarmActive expression

For the same data with Ignition 7.9.12:

@awalker
Is it a known bug of 8.0.5 ?

If I replace the expression:

isAlarmActive("[.]../TM/CPU_USAGE")

with the full path

isAlarmActive("[default]TVG/SYS/ESX01/00001/TM/CPU_USAGE")

I still have the issue

Can you try the latest 8.0.6 nightly and see if you have the same issue? I can reproduce this on 8.0.5, but not on 8.0.6. Still trying to figure out why.

Also, there’s a known issue with using isAlarmActive and the Event Driven execution mode setting of a tag. That hasn’t been addressed yet, so you’ll need to account for that in your 8.0.6 testing (i.e., try either using Tag Groups or a Fixed Rate).

Hi @James.Lorenz,
I’ve upgraded to the last 8.0.6 nightly build.
The issue with isAlarmActive is ok…But I have another issue with this expression tag.

I think the issue occur for the result of isAlarmActive when there are disabled alarms (or perhaps all disabled) in the path of isAlarmActive(“path”)

I confirm this bug is too in 7.9.12

perhaps the same bug as:

Example:

I have one alarm for these expression tag value:
[default]TVG/SYS/ESX01/00001/TA/DEF_CPU_USAGE
Value expression:

isAlarmActive("[.]../TM/CPU_USAGE")

Enabled properties of the alarm is bind to an expression

!({[.]../TC/INHIBER_ALARMES} || {[.]../TS/COND_INHIB_ALARMES})

If the enable expression return True, the value is OK.

If the enable expression return False, the value go to Bad_NotFound !

I use the same pattern to disable alarm based on other expression tag with no problem.

I think the issue occur for the result of isAlarmActive when there are disabled alarms (or perhaps all disabled) in the path of isAlarmActive(“path”)

I am experiencing this issue in 8.0.15 outlined in this post. Has anyone found a workaround?

Thanks

Hi James,

Is there still an issue with the IsAlarmActive on expression tags with execution mode set to event driven?

I am using version 8.1.5.

Time traveling from 2022?

Whoops, that went to fast. :grimacing: