i’m currently having a problem with an opc ua tag with a quality “bad” and a diagnostic of “Bad_DecodingError”. any idea cloud help me a lot .
Details could help us help you. At the very least:
- Ignition Version
- PLC Type
- PLC Driver or OPC Connection type
- OPC Item path in the affected tag
- Gateway log entries that look like they might apply.
- Ignition Version: 8.1
- PLC Type: seimens
- PLC Driver or OPC Connection type : OPC UA
- OPC Item path in the affected tag : nsu=urn:A1230E0148:TRUMPF:UAInterfaces/http://trumpf.com/TRUMPF-Interfaces/;s=98
Yes, need more info, but my guess is a 3rd party OPC UA Server and you’re trying to read a tag with a structure value.
So at the very least we’ll need to know what server it is and if that’s true.
yes i’m using a 3rd party opc ua server
Ah good timing. Is this an S7-1500 or S7-1200? There’s some recent threads about this, but it seems you will need to both enable “legacy DataType dictionaries” in the server and if it’s a 1200 you can’t use the “Server Interfaces” to define an address space.
sorry but after checking with my team the PLC is a BECKHOFF IPC C6930
In that case, change the log level for the logger you find searching for “DataTypeDictionaryReader” to TRACE and then edit/save the OPC UA connection to this PLC.
Once it has reconnected export your logs and upload them. If possible it would be helpful to know the datatype of the tag you’re trying to read. This can be pretty easily obtained using a 3rd party OPC UA client like UaExpert to navigate to the Node and look at its attributes.
Well, that certainly might be the cause. It looks like the server is not responding while we’re reading the dictionary.
You should probably call support and open a case. They’ll give you a place to upload the logs and help you take a Wireshark capture. There may be nothing we can do on our side and you might end up having to work with Beckhoff support instead, but I don’t want to jump to that yet.
thanks for the help and infos.
Hello mootez_bh,
following your posts, it looks like you solved the up mentioned issue.
We are facing here something similar. Also a Trumpf Laser, but a L59.
All the tags are working properly except two or three Messages.
Can you please update this post with the solution, if it's a Ignition setting?
Thanks in advance!
I'm also having a decoding error, two to be specific. A few cursory details:
PLC: Opto22 grv_epic
OPC server: Codesys 3.5.19.10 symbol configuration with OPC features enabled
Ignition Edge version: 8.1.21
1st issue:
I'm reading a 1 level structured data type; I've browsed the OPC tags in the server and added to the tag viewer. The quality error: Bad("Bad_DecodingError: Decoding halted because of invalid data in the stream")
CanRead/Write = Enabled, the tag is enabled
The item path: nsu=CODESYSSPV3/3S/IecVarAccess;s=|var|Opto22-Coretex-Linux-Application.Tuning_Values.SoCParams
What doesn't make sense to me is that i have another, 1 level DUT that has good quality in the same parent path, which has all of the same datatypes (e.g. LREAL):
The item path: nsu=CODESYSSPV3/3S/IecVarAccess;s=|var|Opto22-Coretex-Linux-Application.Tuning_Values.Ratings
The second error:
The second error is occurring on a multilevel DUT, a struct of structs if you will:
it's generating the following quality error:
Error_Configuration("Bad_DataUnavailable: Expected data is unavailable for the requested time range due to an un-mounted volume.")
For path: nsu=CODESYSSPV3/3S/IecVarAccess;s=|var|Opto22-Coretex-Linux-Application.Tuning_Values.Tuning
I've checked in the groov epics standard in-built OPC client and it is reading the tags correctly.
Thanks,
Zach
Is there somewhere in the Codesys software you can get some screenshots or details about the definition of these structures?
Yes
This first example is from the exact GVL that is the source of what is being served by OPC UA:
Here, shows the definition and declaration of a working struct:
Def:
Decl:
Here is the def and declaration of the struct that is not working
Def:
Decl:
For a second case, the struct of structs
Def:
There are many structs within that so here is what it looks like in expansion: