[Bug-12974]Binding Alarm Priority to Expression Evaluating PLC Tag in Array

Ignition Early Access
1

I have been doing some testing with the Alarm Status Table in Vision 8. I would like to change the priority of an Alarm based on logic driven from the PLC. I have tried binding the priority property of the Alarm to an expression evaluating an integer in an integer array from the PLC. For initial testing I have been using a very simple “IF” expression. So far in testing, the “IF” evaluation is always returning a false result even though I am forcing a “1” into the integer from the PLC code. If I use a memory tag in the exact same expression it works as expected. I also tried using a different integer tag in the PLC that was not in an array and it appears to work there as well. I than tried the same expression evaluating the integer in an array in Ignition V7.9 and it worked there. I am suspecting this could be a possible bug. Below is the expression I am using which is bound to the Alarm priority:
if({[~]PriorityArray/PriorityArray_0_}=1,2,0)
PriorityArray is an array of 15 integers, OPC Tag using the Allen Bradley Logix Driver to communicate to the PLC.
I am working with the latest nightly beta build as of today.

2

Can you try two different things for me and let me know if either works?:

1.Change the if statement to:
if({[~]PriorityArray/PriorityArray_0_.value}=1,2,0)
2. If you run the following script from the Script Console, do you get the values you would expect?:

def callback(result):
	system.gui.messageBox(str(result[0].value), "Result")

tagPaths = []
tagPaths.append("PriorityArray/PriorityArray_0_")
system.tag.readAsync(tagPaths, callback)

I am guessing what is happening is not explicitly stating the value property of the tag is causing the full tag object to be evaluated. I also want to confirm that the value that is being expected is being returned when referencing the tag.

Thanks,
Garth

3

Thanks for the quick reply and looking into this.
For the first test, I changed the IF expression to evaluate PriorityArray_0_.value and the expression still evaluated as FALSE and the priority was set to 0 (Diagnostic) even though value is showing “1” in the PLC and Ignition Tag Browser.

For the second test, I executed the script in the Script Console and message box displayed a result of “1”.

4

In attempting to duplicate the issue I have been unsuccessful. This is how I have my system defined and how I attempted to duplicate. The behavior I am seeing is the same in 7.x and 8.0.

  1. Connected an AB ControlLogix device on Firmware version 31 to Ignition
  2. In the Tag Browser, added an array containing 10 DINT (I am going with what we have, this shouldn’t be a big deal). Tag ARRAY_DINT/ARRAY_DINT_0_ is set to a value of 0.
  3. Setup an Int Memory tag that has an alarm that will be activated when a set point is higher than, but not including, 0. Value is initially set at 0. Alarm Priority is bound to an expression of: if({[~]ARRAY_DINT/ARRAY_DINT_0_}=1,2,0)
  4. Vision window is setup to contain a single Alarm Status component
  5. I set the Memory tag value to 5. When this happens the Alarm status table displays a row with the Priority of Diagnostic
  6. I set the Memory tag value back to 0 to clear the alarm. I change Tag ARRAY_DINT/ARRAY_DINT_0_ to a value of 1.
  7. I set the Memory tag value back to 5. When this happens the Alarm status table displays a row with the Priority of Medium

Screenshots just in case I missed something:

48%20AM
48%20AM1433×823 194 KB

I want to make sure that if there is an issue we do get it resolved, but I am not duplicating what you are seeing. Let me know if there is anything different about what I am doing.

Garth

5

The only difference I see from the test you conducted and what I have done is that the Alarm is not configured on a Memory tag. The Alarm is configured on the same array integer as the expression evaluation. When I tested with a memory tag it worked as well. So to be clear - no memory tag is involved, both the Alarm and priority expression are evaluating the PLC array integer tag.

6

Thanks for the clarification. I have been able to reproduce this issue and have logged an internal bug to have it looked at. Because of the tag refactor, some items are happening much quicker. What I am guessing is happening is the value is changed and the alarm and tag write/read are occurring asynchronously. The expression value is getting evaluated before the new value is registered causing the incorrect quality to be reported.

Currently the work around would be to set the Active Delay (seconds) value of the alarm to a non-zero value. Setting it to 0.001 has worked without issue in my testing.

Appreciate your help in replicating this.

Garth

7

Thank you for the update, I’m glad you were able to reproduce. I have tested adding the Active Delay and the expression now evaluates correctly so that is an acceptable work around.