Hello,
I would like to browse my ExtensionObject defined by a DUT in Beckhoff TwinCAT.
In UaExpert, the type is well understood but in Ignition all I have is a Document type and a json object not browsable.
I tried ROOT_FOLDER or OBJECT_FOLDER in OPC Advanced configuration. I unchecked Deprecated Data Type Dictionary Support
How can I do ?
Thank you very much
The Document (JSON) tag is how structured values are handled in Ignition.
Unfortunately this tag type is somewhat limited and does not allow you to further browse its structure or have any kind of virtual member tags or anything like that.
Some people will create additional expression or derived tags to pull the values out of the JSON using jsonGet and jsonSet expression functions if the values absolutely need to be in separate tags (history, alarming, etc...).
Thank you very much for your quick answer. Is it something that is currently being implemented or not at all?
How do people usually avoid code duplication then? Do they simply use the json tricks, OPC UA gateways to flatten or something else?
Most people create Ignition UDTs corresponding to each structured type that contain the derived tags with the JSON expressions.
There's an annoying amount of overhead in working with these types right now. It's not something we're actively working on, but it's something we're actively thinking about, along with other possible OPC UA integration improvements for the future.
Also note that the server you are connected to exposes the structure members as their own tags in the address space, and you can just bring those into Ignition instead (probably still organized by creating an Ignition UDT).
In servers embedded on low power devices / PLCs, like the Siemens S7 stuff, this isn't desirable because it creates significant extra load for the PLC. If your Beckhoff PLC isn't one of the embedded models then it probably has plenty of power to allow you to subscribe to the individual structure members instead of the parent structure value.
Thank you very much for your insights Kevin.
Using StructuredType I successfully leveraged referenced and derived tags to parse the json and avoid too much code duplication.
However, one final thing is limiting me is nested OPC UA UDTs.
I feel like the Document does not integrate them. On the UaExpert screen, you can see the ânestedâ element of testStruct2 but not on the Ignition value of testStruct2. Is it not supported or did I miss an important configuration ?
Last point. Is it a good practice to reference a opc ua tag located elsewhere in the UDT rather than polling it directly in the UDT ?
Thank you very much for your help.
There's no limitation around nested structures, it should be there. Not sure why you're not seeing it.
Make sure the OPC UA connection doesn't have the "legacy datatype dictionary" advanced config option enabled.
Hello, it was not enabled but I selected OBJECT_FOLDER instead of ROOT_FOLDER in advanced config optionâŚ
With ROOT_FOLDER it now works
Is it a good practice to use Value Source reference a OPC UA tag located elsewhere in the UDT rather than polling it directly in the UDT with Value Source OPC?
Changing the browse origin didn't change anything, what probably happened is that you added that nested member and changed the structure definition after Ignition had connected, and when you reconnected the structure definition was read again.
Not sure what you mean by this. Most people create a "Source" OPC tag of type Document inside the UDT, at each level if necessary, that the other derived tags at that level reference.
Yes youâre right, what is the optimal way to rebrowse the tags rather than manually disconnecting and reconnecting?
Sorry I was not clear what I did is I set the OPC tag higher up in the hierarchy:
and then referenced it inside the UDT (Value Source Reference) rather than calling it directly in the UDT (Value Source OPC) and then of course using derived element wise to parse them:
A reconnect isn't required to see tags that are added or removed during browsing, just to see changes to structure definitions. There's no alternative at the moment.
Thank you very much for you help Kevin!
Whatâs the preferred architecture? Setting all OPC sources higher up in the hierarchy and then referencing them and parsing them inside Ignition object (like I did below) or not including the OPC source in the hierarchy and then calling them one by one in Ignition tags using Value Source OPC?
I donât know if there are polling differences or not ? I feel like combining both would do x2 on the number of request but I am not sure how the backend is implemented.
What I've seen is that the source OPC tag is defined directly in the UDT, not at a top level and then referenced with a reference tag. I don't think there's really a difference in terms of performance, it just keeps it all self contained.
Maybe some others who have actually implemented this at scale will see the topic and chime in with what they've done.
Thank you Kevin, I really appreciated your insights and I canât wait to dive deeper into ignition in the coming weeks.
As OPC-UA is one or the most important protocols to integrate machines and equipment in particular to/from SCADA platforms you should not only think about a better native support in Ignition, just do it!
PLCs and other manufacturing software nowadays support structures, events, methods, alarms, historical access⌠Its great that OPC-UA structs can now be read in Ignition, but it comes with some overhead due to the âworkaroundâ. Having transactional context in mind, OPC-UA structs are the recommended (or only way, beside arrays) way to keep data together whenâs transferring via OPC-UA. So please keep improving the native support of OPC-UA - from structs, events, methods and so on to provide competitive OPC-UA clients and servers 
It's not all upside with structures... when you want to write you have to write the entire structure, which introduces a race condition if you change one variable or subset of the structure while the PLC/server changes another.
We do support method calls via scripting already.
Work on event support via Event Streams will begin relatively soon, and some kind of support for receiving and acknowledging Alarms and Conditions after that.
