[BUG-14215] Ignition 8.0.3 - Associated data for alarms are empty when binded to UDT parameter

mazeyrat · June 13, 2019, 12:18pm

@awalker, could you please a new ticket for this issue :

We’ve migrated udts & tags definition from 7.9 to 8.0.3.
Some alarm have associated data used for filtering alarms.
It works fine in 7.9 but not in 8.0.3-SNAPSHOT-11/06/2019

In 7.9, if we look the alarm status component, in the detail sheet, the associated data (for example vue1) are filled

In 8.0.3, if we look the alarm status component, in the detail sheet, all the associated data are blank

UDT definition is OK in 8.0.3, the associated data are binded to UDT parameter.
udt_AMP01.json (51.9 KB)

I don’t known if there is a link but we have those message in the gateway:

Journal	13Jun2019 13:51:52	Error logging alarm event to the database.
java.lang.Exception: Unable to add data to memory buffer, buffer full.

at com.inductiveautomation.ignition.gateway.history.stores.MemoryStore.insertInBuffer(MemoryStore.java:174)

at com.inductiveautomation.ignition.gateway.history.stores.MemoryStore.syncdStoreData(MemoryStore.java:77)

at com.inductiveautomation.ignition.gateway.history.stores.AbstractStore.storeData(AbstractStore.java:223)

at com.inductiveautomation.ignition.gateway.history.stores.MultiStageStore.syncdStoreData(MultiStageStore.java:144)

at com.inductiveautomation.ignition.gateway.history.stores.AbstractStore.storeData(AbstractStore.java:223)

at com.inductiveautomation.ignition.gateway.history.DefaultStoreAndForwardEngine.storeData(DefaultStoreAndForwardEngine.java:144)

at com.inductiveautomation.ignition.gateway.history.HistoryManagerImpl.storeHistory(HistoryManagerImpl.java:196)

at com.inductiveautomation.ignition.gateway.alarming.journal.AlarmJournal.storeEvent(AlarmJournal.java:270)

at com.inductiveautomation.ignition.gateway.alarming.journal.AlarmJournal.storeEvent(AlarmJournal.java:213)

at com.inductiveautomation.ignition.gateway.alarming.journal.AlarmJournalManager.storeEvent(AlarmJournalManager.java:200)

at com.inductiveautomation.ignition.gateway.alarming.AlarmManagerImpl.transitionAlarm(AlarmManagerImpl.java:423)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.processTransition(Alarm.java:851)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.finishTransitionEvent(Alarm.java:808)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.initTransitionEvent(Alarm.java:728)

at com.inductiveautomation.ignition.gateway.alarming.evaluation.Alarm.evaluate(Alarm.java:544)

at com.inductiveautomation.ignition.gateway.alarming.AlarmManagerImpl$AlarmEvaluatorImpl.evaluate(AlarmManagerImpl.java:586)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.alarming.AlarmingActor.processValue(AlarmingActor.java:165)

at com.inductiveautomation.ignition.gateway.tags.runtime.nodes.ExecutableTag.valueChanged(ExecutableTag.java:288)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.AbstractValueGeneratingActor.fireValueChange(AbstractValueGeneratingActor.java:41)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.AbstractValueGeneratingActor.fireValueChange(AbstractValueGeneratingActor.java:34)

at com.inductiveautomation.ignition.gateway.tags.actors.factories.value.opc.OpcActorFactory$OpcActor.setValue(OpcActorFactory.java:664)

at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaSubscriptionSynchronizer$DataValueConsumer.accept(OpcUaSubscriptionSynchronizer.kt:579)

at com.inductiveautomation.ignition.gateway.opcua.client.connection.OpcUaSubscriptionSynchronizer$DataValueConsumer.accept(OpcUaSubscriptionSynchronizer.kt:550)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaMonitoredItem.lambda$setValueConsumer$0(OpcUaMonitoredItem.java:130)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaMonitoredItem.onValueArrived(OpcUaMonitoredItem.java:188)

at org.eclipse.milo.opcua.sdk.client.subscriptions.OpcUaSubscriptionManager.lambda$null$39(OpcUaSubscriptionManager.java:698)

at org.eclipse.milo.opcua.stack.core.util.ExecutionQueue$Task.run(ExecutionQueue.java:119)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at java.base/java.lang.Thread.run(Unknown Source)

I’ve tried to disable/enabled default realtime tag provider with no success.

If I bind the associated data to a constant value, it’s OK !

The issue seem to be relative to the UDT parameter binding

If I bind the associated data with an expression like

concat("test",{vue1})

the result is blank too !

mazeyrat · June 14, 2019, 12:37pm

@awalker, @mgross can you reproduce this bug on your side or did you need extra data ?

mazeyrat · June 18, 2019, 2:56pm

Bump.

awalker · June 18, 2019, 4:29pm

Thank you, @mazeyrat.

We have a ticket for this issue. I’ve linked it above and will let you know when its been resolved.

mazeyrat · June 18, 2019, 6:56pm

Thanks, I stay tuned, that’s one of the main issue blocking me to switch some application from 7.9 to 8.0 !

rberghammer · June 19, 2019, 2:26am

While you’re waiting for a fix, try changing the name of your parameter to something else. I had a similar issue when binding a parameter to a property with the same name. Actually, the parameter can’t match the name of any existing property.

So maybe try creating a parameter called “vue_1” and binding it to your associated data “vue1”.

mazeyrat · June 19, 2019, 6:23am

thanks for the temporary workaround.

mazeyrat · June 27, 2019, 4:53pm

Is this ticket planned for 8.0.3 final ?

mgross · June 28, 2019, 2:06pm

It hasn’t been scheduled yet, but I’ll remind the powers that be about it.

mazeyrat · June 28, 2019, 2:25pm

Thanks, we make intensive use of alarms associated data in 7.9, that’s why this fix is mandatory for us before switching our current projects to Ignition 8 !

awalker · July 5, 2019, 4:06pm

This issue was fixed in the 8.0.3 nightly build that was uploaded today (7/5).

mazeyrat · August 23, 2019, 7:35am

@awalker, @mgross
I have tested with Ignition 8.0.4-NIGHTLY - 21/08/2019 and I have still this issue.

mgross · August 23, 2019, 4:16pm

So…here is the story. I think you actually had 2 problems when you first posted. The first problem was how UDT parameters could not be used at all for alarm properties. This is what was fixed for FB14215. You hit a second problem where both your alarm property name and the udt parameter name are both the same name. In 8.0, the property bindings are handled differently than they were in 7.9, and so having the same name for both isn’t going to work anymore. Unfortunately, you will need to change the name of one of the properties to get everything working properly. Sorry, it’s not the ideal solution, but it should work.

mazeyrat · August 23, 2019, 5:38pm

Ok, I see, I had indeed understood this constrain was not applicable to version from 8.0.3.
I’ll make the change for the associated data name.
It could be interesting that the designer (or the import) alert for such conflict.