I tried to send tags using EAM from the Controller to an Agent, but it failed due to insufficient permissions. I'm not sure how to tell it to run as a particular user? Or how to resolve this?
I have tag editing permissions setup in my tag provider
I tried to send tags using EAM from the Controller to an Agent, but it failed due to insufficient permissions. I'm not sure how to tell it to run as a particular user? Or how to resolve this?
I have tag editing permissions setup in my tag provider
Shot in the dark, but any chance your EAM module licence on the agent was expired?
I get an access denied when forgetting to reset the trial in the test environment.
I've just checked and both gateway EAMs are running out of trial mode. Not sure where to go from here. Support call it is I think
Do role names line up between the two gateways? Service security permissions met? Any security zones accidentally taking effect, maybe?
Yep, I literally backed up the other gateway and restored it to the 2nd gateway, changed gateway name etc. and setup the GAN.
No security zones configured
What do you mean by this?
Hmm, I removed the Tag Editing Permissions on the tag Agent's tag provider to test, and now the Controller is saying "tag provider not found on this gateway"
Let me investigate... it definitely exists though
Ever do anything like duplicate a VM before setting up GAN? How dense is this GAN setup - a few nodes, or a whole forest?
It's just the 2 GWs at the moment, will be 3 GWs at some stage and nope to the duplicating VMs
FWIW, sending a project works successfully
This is my tag send tag paths config (don't ask about the "_fixed" ):
Does sending tags work from inside the designer?
Have you contacted support?
I was just testing this. And the result is, YES, it does work. Maybe I'll create a task from the Designer and see what the difference is...
Looks the same to me...
The Agent task created by the Designer works too...
That particular role didn't exist in the user source required for tag editing.
Well it seems to be working now.. I'm getting new errors now though
Tag JSON import operation failed [default_fixed]types/Packaging: Error_Exception("class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')"
I'm guessing this is some anomaly from a previous upgrade, perhaps from 7 to 8
Time to find the dodgy alarm tag...
I found the type, not sure what's wrong with it though. Copying tag JSON and reimporting it into another type fixed it. I can't import it over the top of the existing one though with error:
Exception: class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')
Ignition v8.1.22 (b2022110109)
Java: Azul Systems, Inc. 11.0.16.1
(same error as the other one)
Any ideas?
A full stacktrace (gateway logs?) Would be helpful
INFO | jvm 1 | 2022/12/01 11:34:37 | E [t.m.provider ] [01:04:37]: Error encountered processing tag edit provider=default_fixed
INFO | jvm 1 | 2022/12/01 11:34:37 | java.lang.ClassCastException: class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.lambda$mergeAlarms$4(TagEvaluationManagerImpl.java:1050)
INFO | jvm 1 | 2022/12/01 11:34:37 | at java.base/java.util.ArrayList.forEach(Unknown Source)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.mergeAlarms(TagEvaluationManagerImpl.java:1040)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.moveOrEditNode(TagEvaluationManagerImpl.java:934)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEditInternal(TagEvaluationManagerImpl.java:421)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEditInternal(TagEvaluationManagerImpl.java:469)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEditInternal(TagEvaluationManagerImpl.java:469)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEditInternal(TagEvaluationManagerImpl.java:469)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEdit(TagEvaluationManagerImpl.java:321)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.saveTagConfigInternal(TagProviderImpl.java:813)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.lambda$importTagsAsync$25(TagProviderImpl.java:1140)
INFO | jvm 1 | 2022/12/01 11:34:37 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.lambda$exec$5(TagProviderImpl.java:462)
INFO | jvm 1 | 2022/12/01 11:34:37 | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
INFO | jvm 1 | 2022/12/01 11:34:37 | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
INFO | jvm 1 | 2022/12/01 11:34:37 | at java.base/java.lang.Thread.run(Unknown Source)
INFO | jvm 1 | 2022/12/01 11:34:37 | E [t.m.provider ] [01:04:37]: Error processing edit for tag path '[default_fixed]_types_/Packaging/Wine Delivery/Packaging Transfer Sequence 1': Error_Exception("class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')") provider=default_fixed
INFO | jvm 1 | 2022/12/01 11:34:37 | I [t.m.provider ] [01:04:37]: Finished import in 3 ms
I would send you the tag in error, but exporting it and re-importing it removes the issue...
Update:
The type has a parent type. It looks like the only thing changed are the udt parameters are overridden... not sure why it even exists in that case tbh...
If I copy the type and paste it (not JSON), the error follows it.
If I change the parent type of the type, the error is gone. However, if I set it back, the error comes back
There are actually a number of tags in my project that have this issue, it seems. It's really hampering my ability to use EAM The most time consuming part is trying to locate the bad tags, as the tagpath doesn't get reported, I have to do it by trial and error, literally sending a selection of tags and waiting for it to fail, then narrow down the selection until finally I end up with a single tag/UDT
And RE my OP, if I add the tag editing permission back into my tag provider, I'm still seeing the original issue Bad_AccessDenied("Insufficient Tag Provider Edit Permissions")
when trying to send tags to this tag provider
Sorry to possibly hijack a thread, but we upgraded our production server to 8.1.22 yesterday and very similar errors as what @nminchin is getting later in this thread started showing up in our logs. We are not using EAM. Our errors all seem to be immediately after a Sparkplug edge node rebirths, when MQTT Engine is trying to merge any property changes into the tag:
INFO | jvm 1 | 2022/12/05 15:47:27 | E [t.m.provider ] [15:47:27]: Error encountered processing tag edit provider=MQTT Engine
INFO | jvm 1 | 2022/12/05 15:47:27 | java.lang.ClassCastException: class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.lambda$mergeAlarms$4(TagEvaluationManagerImpl.java:1050)
INFO | jvm 1 | 2022/12/05 15:47:27 | at java.base/java.util.ArrayList.forEach(Unknown Source)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.mergeAlarms(TagEvaluationManagerImpl.java:1040)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.moveOrEditNode(TagEvaluationManagerImpl.java:934)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEditInternal(TagEvaluationManagerImpl.java:421)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.runtime.TagEvaluationManagerImpl.processEdit(TagEvaluationManagerImpl.java:321)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.saveTagConfigInternal(TagProviderImpl.java:813)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.lambda$saveTagConfigsAsync$13(TagProviderImpl.java:770)
INFO | jvm 1 | 2022/12/05 15:47:27 | at com.inductiveautomation.ignition.gateway.tags.TagProviderImpl.lambda$exec$5(TagProviderImpl.java:462)
INFO | jvm 1 | 2022/12/05 15:47:27 | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
INFO | jvm 1 | 2022/12/05 15:47:27 | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
INFO | jvm 1 | 2022/12/05 15:47:27 | at java.base/java.lang.Thread.run(Unknown Source)
INFO | jvm 1 | 2022/12/05 15:47:27 | E [t.m.provider ] [15:47:27]: Error processing edit for tag path '[MQTT Engine]Edge Nodes/sitename/35265/Slave13/level': Error_Exception("class com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration cannot be cast to class com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration (com.inductiveautomation.ignition.common.alarming.config.BasicAlarmConfiguration and com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration are in unnamed module of loader 'app')") provider=MQTT Engine
The tags in MQTT Engine that hit this do continue receiving value changes, but stop receiving any property changes (e.g. engUnit, engLow, engHigh) from the edge node.
I have not tried any workarounds yet, but will try manually editing tags like mentioned and let you know how that goes.
FYI, the BasicAlarmConfiguration error we were getting has been confirmed as a regression bug in 8.1.22. We contacted CirrusLink support, and they were able to recreate the issue and confirm it was from changed behavior in Ignition, and sent their notes over to IA who have now opened a ticket and are targeting a fix on an 8.1.24 nightly build. Not sure if the exact same issue was affecting your EAM tag moves, but it seems likely.
Sounds likely. It's not EAM that was causing the issue, it was simply trying to replace some of the UDT definitions via any method (EAM, tag browser, etc).
That's disappointing to hear it's a regression.. The reason we upgraded to version 8.1.22 was because of another regression. Unfortunately it seems to be a common theme lately
Back to this issue. Same error, different reason. This time, I'm getting just this in the wrapper:
Tag JSON import operation failed [default_fixed]Test Tag Bobafet: Bad_AccessDenied("Insufficient Tag Provider Edit Permissions")
I've checked the Security Services on the remote gateway for tag access and it's set to ReadWriteEdit: