[bug-4173]Alarms Tag structured changed with 8.1?

Ignition
1

Hello I am updating from 7.9.9 to 8.1.9 and i am in testing process and i noticed that the structure of the alarms tag have changed.
Old:

image
image252×561 4.63 KB

New:
image
image252×745 17.9 KB

That is causing me some problems cause i was using the AlertActive and now i guess it had been replaced with HasActive?.

And the path isn’t the same either…
Before:
{PLC_NOLTEC/Silos/Silo B1/Alarmes/Active.AlertActive}
After 8.1
{[default]PLC_NOLTEC/Silos/Silo B1/Alarmes/Active/Alarms.HasActive}

Will i have to change all my expressions and object that use alarming with 8.1?

2

Any legacy paths should continue to work. You are encouraged to migrate to the new syntax, but we take some pains to ensure that the old paths should work.

3

I will jump in this discussion to say that in my experience the legacy paths DO NOT work. Thankfully we developed a script that could go through the window’s binding setup and change it automatically. It was still painful to deal with but just add it to the list of things that have to be done as part of the upgrade migration. I recommend using templates that take the base tag path and derive alarm information from there. It makes it much easier to deal with changes to the sub properties.

4

I can confirm that it’s not working, i had objects that would change color if one or more alarm was active but the object had the bad quality overlay.
I change the Expression from {PLC_NOLTEC/Silos/Silo B1/Alarmes/Active.AlertActive} to {[default]PLC_NOLTEC/Silos/Silo B1/Alarmes/Active/Alarms.HasActive} and the overlay disapear.

5

These might be useful as well to know

1 Like
6

@gilles.levesque,

I am attempting to duplicate this issue, but I haven’t been successful. As Paul mentioned, we do have code that will map the 7.9 attributes to their 8.x counterparts. One thing I am seeing is some of the mappings are returning Error_TypeConversion messages when a value doesn’t return an expected type because instead of a 0 or -1 returned like in 7.9, we are returning None. Although this doesn’t look to be the case for the specific properties you are mentioning.

Can you please run the following script for me in the Designer Script console and let me know what returns?:

type(system.tag.readBlocking(['PLC_NOLTEC/Silos/Silo B1/Alarmes/Active.AlertActive'])[0].value)

You should get <type 'bool'>, but if you get something else I would like to know.

Also if you could DM me an example project resource and tag export that is experiencing this, it might help me identify what the problem is.

Thanks,
Garth

7

Hello. I am back from Vacation today…

Here is a print screen of the result of the script you wanted me to execute. This one was executed from 7.9.9

image001.jpg
image001.jpg1056×394 24.4 KB

And this is the result when executed from 8.1.9

image003.jpg
image003.jpg1055×404 19.7 KB

So that seem to work.

8

Ok here w how I encounter the problem.

We are using Tab navigation for our vision projects. When an alarm occurs in one of the sus system I want to make the corresponding Tab to flash red. To do that, I’ve create a custom property for each tab for alarm Status. I also add a custom property for tabs colors using cell update.

My Alarm Tags are configured using words where each bits is corresponding to an alarm.

So for the AlarmSts custom properties I was checking the if one of the alarm word has the AlertActive status through an Expression:

Here is the version of the expression after modification.

image001.png

Prior to the modification it was pointing to {PLC_NOLTEC/Silos/Silo B1/Alarmes/Active.AlertActive} and I had the had the bad quality overlay on the tabs

9

@gilles.levesque,

Based on the information you have shared, PLC_NOLTEC/Silos/Silo B1/Alarmes/Active.AlertActive looks to be evaluating in a manner we would expect in 8.1. By any chance are any of your expressions using any of the following alarm properties from 7.9?

.AlarmHighestAckPriority
.AlarmHighestUnackPriority
.AlertCurrentSeverity

What I am seeing is there is a difference between the 7.9 and 8.x behavior when there isn’t an active alarm and we are returning null in 8.x instead of the -1 that was returned in 7.9. This causes the expressions to fail because the first parameter isn’t a value it expects.

Based on what you noted in your second screenshot, I still am unable to duplicate the issue you noted.
Is there any chance that I could get any of the following via a DM?:

  1. An export of the 7.9 version of the Vision Window you were seeing these problems with and an export of the related tags
  2. A screenshot of the diagnostics window when the error is present (Right click the component in the Designer > Run Diagnostics)

Thanks,
Garth