OPCUA UDT can't be parsed by Ignition

dawei.liu · August 9, 2019, 2:47am

Hi,

I created two UDT with third part OPC UA server, one is simple struct, the other is nested struct. Both of them can’t be parsed by Ignition OPCUA connection with below logging info.

Both of UDTs can be parsed by UaExpert (a OPCUA client tool) correctly as shown in below snapshot.

Anyone could help to give suggestion of it?

Thanks in advance

Kevin.Herron · August 9, 2019, 11:44am

Hmm. Those messages indicates some part of the datatype information is missing from the address space.

Those 2 Nodes you’ve got showing in UaExpert should each have an inverse reference of type HasDescription (so, descriptionOf) pointing to the Node representing the encoding id. The logs are complaining that this wasn’t found for some reason.

dawei.liu · August 9, 2019, 1:19pm

@Kevin.Herron

The UDT was defined in a python-opcua server with reference below python scripts.

github.com

FreeOpcUa/python-opcua/blob/master/examples/server-create-custom-structures.py

from opcua import ua, Server
from opcua.common.type_dictionary_buider import DataTypeDictionaryBuilder, get_ua_class
from IPython import embed


class DemoServer:

    def __init__(self):
        self.server = Server()

        self.server.set_endpoint('opc.tcp://0.0.0.0:51210/UA/SampleServer')
        self.server.set_server_name('Custom structure demo server')
        # idx name will be used later for creating the xml used in data type dictionary
        self._idx_name = 'http://examples.freeopcua.github.io'
        self.idx = self.server.register_namespace(self._idx_name)

        self.dict_builder = DataTypeDictionaryBuilder(self.server, self.idx, self._idx_name, 'MyDictionary')

    def __enter__(self):
        return self

This file has been truncated. show original

The python-opcua may not implement the fully OPCUA protocol, but at least the UDT in python-opcua as shown in previous snapshot can be parsed by UaExpert or the UA.Net Standard C# library.

So is there any work around to parse it in ignition?

Kevin.Herron · August 9, 2019, 2:26pm

This will probably have to be fixed in either the Milo SDK or the python-opcua SDK. I’ll see if I can get that sample server running and figure out what’s going on. There’s no workaround that I can see.

dawei.liu · August 9, 2019, 2:31pm

@Kevin

Thanks for your warmly help.

Kevin.Herron · August 9, 2019, 3:46pm

This is a bug in the pyopcua server, although it’s not exactly what I expected it to be.

They do seem to have all the pieces of the address space in place, but there’s a bug in their browse service when we ask specifically for Inverse references of type HasDescription during one of the steps. It just responds saying there are no references.

If a browse is made on the same node for Inverse references of any type then it responds with multiple references, including the HasDescription reference it should have returned when asked for only references of that type.

I’ll open an issue on their GitHub repo but I don’t know how responsive they will be.

edit: https://github.com/FreeOpcUa/python-opcua/issues/876

dawei.liu · August 10, 2019, 12:05am

@Kevin.Herron
Really appreciate your help. I will try to see if there is any other opcua sever that I could use to create dictionary mapping UDT.