# OPC UA ExtensionObject not browsable 8.3 **URL:** \ **Category:** Ignition\ **Tags:** opcua, ignition83\ **Created:** [October 30, 2025, 10:46am UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814 "2025-10-30T10:46:44Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 10:46am UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/1 "2025-10-30T10:46:44Z")
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 ![Screenshot 2025-10-30 at 11.41.55](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/7/57f36fc83f6bebdb25bd349b782918a981d9b364.jpeg) ![Screenshot 2025-10-30 at 11.42.30](https://us1.discourse-cdn.com/inductiveautomation/original/3X/2/9/299b4e1e6e5f2b1fa0e47149e266f8a7ef70fb83.png) ![Screenshot 2025-10-30 at 11.41.45](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/d/ddc379962bafe9349e36882e80e80a4b5091f0e7.jpeg) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 12:07pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/2 "2025-10-30T12:07:14Z")
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...). ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 12:55pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/3 "2025-10-30T12:55:05Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 1:10pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/4 "2025-10-30T13:10:30Z")
Most people create Ignition UDTs corresponding to each structured type that contain the derived tags with the JSON expressions. > [@OPC UA struct data type?](https://forum.inductiveautomation.com/t/opc-ua-struct-data-type/26905/2): > > You can take advantage of reading whole structs in OPC UA servers as of Ignition 7.9.12 and 8.0.0. When you bring the tag in you’ll notice Ignition presents a JSON value. The strategy here is a little involved but it works. For each of the UDTs you’ll be subscribing to in the PLC you make a corresponding UDT in Ignition. It should have a “Source” OPC tag member that will correspond to the Node with the struct value in the server and as a result have a JSON value in Ignition. Then for each memb… 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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 1:16pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/5 "2025-10-30T13:16:23Z")
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. ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 4:55pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/6 "2025-10-30T16:55:24Z")
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 ? ![Screenshot 2025-10-30 at 17.49.07](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/d/4deca9afe3ee33259acb97d12a56d8b361bef68d.png) ![Screenshot 2025-10-30 at 17.49.13](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/0/b0d95c30bd72a3aa6c0e6f4f6ac0d43800fff460.jpeg) ![Screenshot 2025-10-30 at 17.49.49](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/e/9e9b69c9f77c7e624a6afe2bc232d36a3f53023d.png) 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 ? ![Screenshot 2025-10-30 at 17.52.43](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/a/1abdcd1b56c53f2d774cd211ebb097ef9c51bf76.png) Thank you very much for your help. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 5:01pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/7 "2025-10-30T17:01:10Z")
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. ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 5:13pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/8 "2025-10-30T17:13:17Z")
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? ![Screenshot 2025-10-30 at 17.52.43](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/a/1abdcd1b56c53f2d774cd211ebb097ef9c51bf76.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 5:20pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/9 "2025-10-30T17:20:34Z")
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. > [@matteo.berthet](#): > > 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? 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. ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 5:30pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/10 "2025-10-30T17:30:08Z")
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: ![Screenshot 2025-10-30 at 18.26.56](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/5/b543a9acca5348e248e235846f9324897636827a.png) 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: ![Screenshot 2025-10-30 at 18.28.17](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/7/073dfe903fb926a3d7b457d381a189982bba276e.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 5:31pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/11 "2025-10-30T17:31:42Z")
> [@matteo.berthet](#): > > Yes you’re right, what is the optimal way to rebrowse the tags rather than manually disconnecting and reconnecting? 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. ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 5:39pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/12 "2025-10-30T17:39:07Z")
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. > [@matteo.berthet](#): > > Sorry I was not clear what I did is I set the OPC tag higher up in the hierarchy: > > ![Screenshot 2025-10-30 at 18.26.56](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/5/b543a9acca5348e248e235846f9324897636827a.png) > > 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: > > ![Screenshot 2025-10-30 at 18.28.17](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/7/073dfe903fb926a3d7b457d381a189982bba276e.png) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 5:49pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/13 "2025-10-30T17:49:24Z")
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. ---
**Author:** ![matteo.berthet](https://avatars.discourse-cdn.com/v4/letter/m/bbce88/32.png) [@matteo.berthet](https://forum.inductiveautomation.com/u/matteo.berthet)\ **Post date:** [October 30, 2025, 5:55pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/14 "2025-10-30T17:55:09Z")
Thank you Kevin, I really appreciated your insights and I can’t wait to dive deeper into ignition in the coming weeks. ---
**Author:** ![Andre\_Hennecke](https://avatars.discourse-cdn.com/v4/letter/a/e95f7d/32.png) [@Andre\_Hennecke](https://forum.inductiveautomation.com/u/Andre_Hennecke)\ **Post date:** [October 30, 2025, 7:22pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/15 "2025-10-30T19:22:23Z")
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 🙂 ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 30, 2025, 7:38pm UTC](https://forum.inductiveautomation.com/t/opc-ua-extensionobject-not-browsable-8-3/111814/16 "2025-10-30T19:38:52Z")
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.