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


@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


the result is blank too !



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



Bump. :sos:



Thank you, @mazeyrat.

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

1 Like


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



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”.



thanks for the temporary workaround.



Is this ticket planned for 8.0.3 final ?



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



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 !



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

1 Like


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



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.

1 Like


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.