I’m asking for a colleague, but also interested in the answer.
We have a new greenfield project using Siemens PLCs and I’m wondering which way to go in terms of comms to them in Ignition.
Should we use the onboard OPC-UA server on the PLCs, or should we use the Ignition driver with crappy (no fault of IA) direct addressing?
For sanity’s sake, I would go with OPC-UA, but I’ve heard there are tag count limitations for this where beyond them the PLC starts to fall over and not handle the load and these counts are a lot lower than if direct addressing (correct me if wrong).
Other questions:
- is either faster than the other?
- is either more reliable?
- what about diagnostics? Ignition Devices have nice throughput indicators (load factors etc.) whereas OPC-UA doesn’t? (or does it?)
- what about setup/configuration and diagnosing any comms issues?
- anything else?
1 Like
My vote is for OPC UA unless you exceed the supported tag / MonitoredItem count (there’s documentation from Siemens with recommendations based on the model).
OPC UA is going to be more reliable and easier to configure (kind of, see below) or troubleshoot. You don’t need all the diagnostics Ignition drivers have because you’ll OPC UA subscriptions report only when the value changes, there’s no polling of the device involved.
The cons are the tag/item limit and the configuration burden of needing to define UDTs in Ignition that mirror the structured values you’ll access in the PLC and use derived tags + jsonGet/jsonSet to pick out all the members, because structured OPC UA values come into Ignition as a JSON object. See OPC UA struct data type? - #2 by Kevin.Herron
1 Like
Thanks Kevin! That was my hope.
From @Stevenson.Yuan 's post, I assume that we can define a custom property on the derived tags to hold the key to pull from the source tag and can then reference this in the read/write expression? (so that you don't have to edit the json function args for both props and instead just set the key in one place)
e.g. jsonGet({source}, {tagKeyName})
Don’t know, haven’t tried that 
Ah, also, I’m assuming you are talking about using S7-1500s. These have had, and still have, support for the OPC UA 1.03 datatype dictionaries, which is currently required by Ignition. OPC UA 1.04 defined a new, much simpler/saner way for servers to expose datatype information but Ignition is going to be stuck on 1.03 for a while longer. Consequently, the S7-1200 is not a viable option, since Ignition can’t read whole structured values from it, and reading individual tags is a performance killer on top of the already significantly lower performance of the server in the S7-1200.
1 Like
Thanks Kevin, yes we'll be using 1500's but good to know!
Should this be in the doco? @Paul.Scott
https://docs.inductiveautomation.com/display/DOC81/Third+Party+OPC+Servers
We use OPC UA of the S7-1500 extensively. One gateway has about 40 controllers connected. Setting up the connections are quick and painless. Just approve the certificate on the redundant gateway manually, else it won't connect on failover.
It is important to go with the structured reads and use jsonGet(). We use the 1513 mostly and it supports 10000 subscriptions. We have not come close to that limit by reading structs.
We also use system.opc.write for some odd configuration items that are written very infrequently and do not form part of the struct that is written from Ignition. @Kevin.Herron, any danger in that?
As Kevin said, stay away from the 1200.
2 Likes
No this is fine.
You can also use system.opc.read or even a slow Tag Group in OPC Polled Mode for data you need to acquire infrequently, which will lower the MonitoredItem count. Just make sure it's actually infrequent and you don't end up doing frequent polling on top of OPC UA.
I have talking to Siemens about Monitored Item count and Registered Read/write.
If the the tag i configured as Registered Read/write in the Client the 1515 can handle 20.000 tags and that is a hole lot more than 2000. So I think i worth exploring.
I don't know the difference between those to configuration and a bit new i Ignition (for the moment).
But can Ignition configure the tags as Registered Read/write?
As far as I can tell from the docs, registering nodes only improves performance when you’re doing large repeated reads, not using subscriptions.
It might still be worth looking into for when people resort to using polled mode tag groups, though
If i "only" have 2000 tags from the PLC, then is not enough for some of the bigger production lines where there are a lots of pumps, valves, analog input, ect.
A Siemens 1515 i actually i quite big PLC that can run large production lines.
Do you know how the to make a Registered Read/write tags in Ignition? then I can do some test on how i works.
It's not possible to use the RegisterNodes service from Ignition right now.
Any testing you do would need to use another client that supports it or just be a coded from scratch test that uses some OPC UA SDK.