Siemens OPC-UA or Ignition Siemens Driver with direct addressing?

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?

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 :upside_down_face:

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 2000 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.

1 Like

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.