Hi,
Using Ignition 8.1.42 I am trying to read OPC UA Struct from a ControlLogix 1756-L82E into an Ignition Document as I typically do using Siemens S7-1500 without issues.
Result: Bad("Bad_DecodingError: Decoding halted because of invalid data in the stream.")
Using UA Expert:
Cannot find anything obvious on the logs for DataTypeDictionaryReader TRACE.
Why? I understand this is often necessary with the Siemens processors, but Logix's public native protocol doesn't suck for UDTs. (It doesn't come in as a Document type, but is otherwise fully functional.)
Siemens S7-1500 OPC UA Server is very performant with data structures, minimum effort to mirror whole PLC UDTs into Ignition UDTs for performance reasons, scalability, standardization and so on....I want to do the same with AB.
It doesn't come in as a Document type, but is otherwise fully functional
Limiting the above mentioned....Document datatype is a win-win
Documents lose some of the datatype information of inner members, breaking writeback outside of writing entire documents.
Subscription to documents also means every internal change has to send the entire document, blowing up your bandwidth. It is the opposite of performance and scalability.
Subscribing to document types is a workaround for PLCs that have lame public protocols and/or artificial point count limits. Any other use over the wire is a mistake, in my not-so-humble opinion. That you find it convenient doesn't convince me that it is a good idea.
Also note that Rockwell sets the CPU priority of OPC tasks lower than anything else in the PLC. Probably because OPC internal operations are a substantial burden on CPUs, and the native protocol is way more efficient.
Also using OPCUA on Rockwell is pointless given they put the comms as last priority and limit the tags to 600 across the board.
Given the performance optimisation on the Logix Driver(s) for Ignition, it is better to just have a UDT that uses the Rockwell driver with the same tag structure as the one you have for the same data in a Siemens PLC.
I would hazard a guess that when 8.3 comes out with the upgraded Siemens driver, you will be better off using the native Siemens driver for better support and optimisation.
Also note, if you like the Document data type for convenience within your user interface, you should know that a tag read of base path of a UDT delivers a document-like value of the entire UDT, no matter how the values in the UDT got there. UI convenience is not an excuse to use a suboptimal communication technique.
Take in account it all depends to the solution your are building. In practice when well designed I have seen better results using Document subscriptions than not. For many reasons including data handling in general. Writeback is not an issue since you know your data struct you can always write back to specific datapoints.
Subscription to documents also means every internal change has to send the entire document, blowing up your bandwidth. It is the opposite of performance and scalability.
Not if you build your datatypes with nested groups combined with specific scan classes/groups
The tradeoff of native protocol vs all other benefits of Document Struct does not seem to be worth it at least not for my case. Siemens OPC UA server is powerful enough to handle 1000 datapoints at 1 second sampling per OPC connection (+ more). Bandwidth is not an issue and tested in many scenarios.
Example:
The major benefit is going from 200K datapoints (20 PLC) to 40K OPC UA nodes Ids with driven expression tags when needed. The rest is a plus.
That you find it convenient doesn't convince me that it is a good idea.
Not trying to convince you just yet but test it at scale and might change your view
An Ignition benefit we all should be happy about 
Not going to hold my breath. There are lots of reports of performance problems with Rockwell's OPC implementation. I am intimately familiar with the reasons Rockwell's native protocol is so superior. (I stress-test my alternate driver with tens or hundreds of thousands of data points per PLC, at one-second intervals.)
I'm also familiar with Ignition pathological performance due to proliferation of expression tags and tag scripting. Ignition's OPC tags are most efficient when used directly, minimizing expressions and derivations.
I am not a Siemens user/integrator, so I have not been forced to do things the hard way, and then suffer from Stockholm syndrome.
Siemens may be that powerful, but the Rockwell one is 600 datapoints across all all connections, at a rate limited by every other Ethernet/IP or messaging connection in the entire PLC.
It's possible that they do not support the legacy datatype dictionary at all, and only support the DataTypeDefinition attribute introduced in OPC UA 1.04.
Ignition is lagging behind in support for that, but it's been implemented for Ignition 8.3.
Does DataTypeDictionaryReader logging on TRACE yield anything after doing an edit/save on the OPC UA connection?
This isn't entirely true, but I agree that it's so limited that it's essentially useless except for maybe high level SCADA systems that need to grab some data points out of a PLC.
The product managers at all the major PLC manufacturers seem to be completely out of touch about the number of tags/points their customers want to bring into their SCADA systems.
The kicker with those numbers is that if you're using UDTs, the UDT tag itself even "counts" as a node, so if you have 10 DINTs in a UDT (as a basic example), that counts as 11 nodes, so depending on comlpexity of UDTs and quantity of them, you can use up nodes pretty fast.
I think Rockwell did this almost as a proof of concept and hopefully with the 1756-L9x series coming out later this year they have a true OPC-UA server in them (but I'm not holding my breath as it's not mentioned in any slides). The only other use for it could be cross communications between other devices that may support OPC-UA but not Ethernet/IP so you can pass interlocks or small amounts of other data between systems.
I'm perhaps being a little unfair, because I know from talking to some of the engineers that it's pretty difficult to add OPC UA support to existing PLCs because the hardware is extremely limited, and it only gets harder the older the PLC is.
But even the native protocols can't deliver the performance or tag quantities people really want these days.
This. And for a reason. It is built, at the custom ASIC level, for a trouble-free 25+ year lifespan in industrial temperatures and contaminated environments.
I don't foresee any solution that doesn't include communication-friendly bulk data structures in the end-user's PLC code design. It is the only solution to this:
The only way to speed up the overall system is to move data in bulk and let the IT side, where computational performance is not a problem, do the payload decoding into the individual tags. And then the IT side does the change detection for forwarding.
The business model sucks...notice the difference between jumps 600, 1200, 10000 nodes with a price jump of almost $3,000 
Yeah, everyone always wants more data, and I even went through an exercise of stress testing both the IA driver and Phil's driver against my AOIs I have built to determine the best structure and layout that I can standardize on to optimize it for both drivers (the results somewhat surprised me as I was able to get the IA driver to get close in performance from the Ignition side to Phil's driver although the IA driver had a much higher Class 3 comm load on the PLC). I was testing it with 1500 Ignition UDT instances talking to a total of 106.5k PLC tags on a single L83 PLC (60k @ 1 sec, 37.5k @ 5 sec, and 9k @ 60 sec).
My guess is they don't. I cannot see anything for the TRACE. Will test 8.3 as soon as it is out.
My guess is it's somewhat of a memory limitation more than anything since they share a common chipset with memory being the only difference between models of the same product line.
