Siemens 1500 PLC to PLC comms via OPC UA?

[russg]

Hi,

I'm investigating different network protocols for PLC to PLC comms, and PLC to SCADA. OPC UA seems to be a very useful protocol that I'm starting to learn more about, and it looks like one of the best options for Siemens PLCs that want to stick to optimized data blocks.

I'm having a play around with the Siemens block OpcUaClient at the moment but struggling to get it working.

Have any of you used OPC UA to transfer data between Siemens PLCs before? If so, what is your opinion on using it over the other Siemens data transfer methods?

Thanks

 

[baref00t25]

We use the OPC/UA for Siemens to SCADA, but do not use it for PLC to PLC communication. It is a bit slow for PLC to PLC transfers in most cases; however if you are working with two different manufacturers that might be a good option. We find gateways and couplers to be the most robust for communicating between different brand PLC's.


Here's a link for different protocols for Siemens.

https://support.industry.siemens.com/cs/document/109780503/libraries-for-communication-for-simatic-controllers?dti=0&lc=en-US

 

[mk42]

OPC UA is a great solution for PLC -> SCADA. For PLC -> PLC, it can work, and there may be situations where it is advantageous, but it also has downsides.

In my experience, I-Device is the default communication choice, and anything else is done if I-device doesn't suite the job. It is a simple IO mapping between two PLCs, with no special comm instructions involved. It can be essentially as fast as you want; it uses the normal Profinet communication mechanisms, and single digit millisecond update rates is easily achievable. The main downside is that A) based on profinet, so 3rd party support is quite variable B) the PLCs need to be on the same local network (no routing, except a special device like PN/PN coupler). Safety is also very easy over this mechanism.

OPC UA would be great if you want a standard tag based interface between machines, esp if industry standards like PackML are involved. Also very useful for several communication partners. Not as simple to configure, though, as you're seeing, and data rates tend to be in the 100s of ms.

Open socket TCP/UDP comms are also common, for implementing your own comm protocol, when needed. Also good for sending large amounts of data as needed (acyclic) vs the cyclic profinet.

Modbus TCP tends to be the "lowest common denominator" when it comes to 3rd party communication, especially to older/cheaper systems. I wouldn't recommend it in any situation, but sometimes it's your only choice.

 

[russg]

We use the OPC/UA for Siemens to SCADA, but do not use it for PLC to PLC communication. It is a bit slow for PLC to PLC transfers in most cases; however if you are working with two different manufacturers that might be a good option. We find gateways and couplers to be the most robust for communicating between different brand PLC's.


Here's a link for different protocols for Siemens.

https://support.industry.siemens.com/cs/document/109780503/libraries-for-communication-for-simatic-controllers?dti=0&lc=en-US

Hi,

Thanks for the feedback. It does sound like OPC UA is a good option for different types of PLC's.

 

[russg]

OPC UA is a great solution for PLC -> SCADA. For PLC -> PLC, it can work, and there may be situations where it is advantageous, but it also has downsides.

In my experience, I-Device is the default communication choice, and anything else is done if I-device doesn't suite the job. It is a simple IO mapping between two PLCs, with no special comm instructions involved. It can be essentially as fast as you want; it uses the normal Profinet communication mechanisms, and single digit millisecond update rates is easily achievable. The main downside is that A) based on profinet, so 3rd party support is quite variable B) the PLCs need to be on the same local network (no routing, except a special device like PN/PN coupler). Safety is also very easy over this mechanism.

OPC UA would be great if you want a standard tag based interface between machines, esp if industry standards like PackML are involved. Also very useful for several communication partners. Not as simple to configure, though, as you're seeing, and data rates tend to be in the 100s of ms.

Open socket TCP/UDP comms are also common, for implementing your own comm protocol, when needed. Also good for sending large amounts of data as needed (acyclic) vs the cyclic profinet.

Modbus TCP tends to be the "lowest common denominator" when it comes to 3rd party communication, especially to older/cheaper systems. I wouldn't recommend it in any situation, but sometimes it's your only choice.

Hi,

thanks for the feedback.

i-device is a great option for fast comms that are needed, but the problem with it is when transferring large data sets, UDT's etc. As I understand it, you can't use a UDT in i-device or the PN/PN couplers, so if you have a large UDT that you want to change a few times during development, you have to write each part of the data type a few times in the comms link.

As i'm looking into OPC UA performance on S7 1500's, it does look like a reasonable amount of data can be transferred in single digit ms time with a 1518 PLC, but it still maybe be better to use open socket option if it isn't time critical.