S7-1500 to PC Communications

Both libnodave and Snap7 use a long time ago S7-300/400 reversed engineering protocol that in the more recent S7-1200 and 1500 can not access optimized DBs.

For me it seems clear that for new installations with S7-1500 the protocol to be used should be OPC UA that offers several advantages

lfe said:

Both libnodave and Snap7 use a long time ago S7-300/400 reversed engineering protocol that in the more recent S7-1200 and 1500 can not access optimized DBs.

For me it seems clear that for new installations with S7-1500 the protocol to be used should be OPC UA that offers several advantages

Click to expand...

I agree. Interestingly, most comms drivers I've seen or worked with seem to use that protocol to communicate with the S7-1500's.

This being said, some already bring OPC UA Clients.

Do you have any experience with OPC UA and the S7-1500's?

cardosocea said:

I agree. Interestingly, most comms drivers I've seen or worked with seem to use that protocol to communicate with the S7-1500's.

Click to expand...

Most third parties are still using the 300/400 driver for the 1500, you mean? Yeah, Siemens never shared the details of the new upgraded protocol, so they're left with the already reverse engineered older protocol.

cardosocea said:

This being said, some already bring OPC UA Clients.

Do you have any experience with OPC UA and the S7-1500's?

Click to expand...

I know that OPC UA supports multiple types of reads and writes, and the performance can vary a ton depending on if you use them appropriately (probably meaning: the way Siemens wants you to). Also, the way you structure your data seems to make a big difference. The data structure is up to the PLC programmer, so that is something you can change if needed. The type of read/write is up to the OPC UA client, which often means you have to hope your SCADA system is optimizing things correctly.

mk42 said:

Most third parties are still using the 300/400 driver for the 1500, you mean? Yeah, Siemens never shared the details of the new upgraded protocol, so they're left with the already reverse engineered older protocol.

Click to expand...

Perhaps to force OPC UA?

Siemens never shared the details of the new upgraded protocol, so they're left with the already reverse engineered older protocol.

Click to expand...

I have seen German companies that sell communication drivers for 3d party systems that claims they support optimized datablocks. If that information is shared from Siemens or if they have decoded the new protocol is unclear

Deltalogic

AGLink also supports the S7-1200 / S7-1500 with optimized
block access and masters the import of symbols directly from the TIA Portal versions 11, 12, 13, V14 and V15.

Click to expand...

Bratt said:

I have seen German companies that sell communication drivers for 3d party systems that claims they support optimized datablocks. If that information is shared from Siemens or if they have decoded the new protocol is unclear

Click to expand...

I've decoded about 95% of the new protocol, the parts you'd need for get variable access is 100% complete.
I've written a Wireshark dissector which shows you whats going on (https://sourceforge.net/p/s7commwireshark/code/HEAD/tree/trunk/src/s7comm_plus/).

The problem is not the protocol itself, it's the authentication you need to implement in your driver. The only option to get the needed keys you need is to disassemble Siemens binaries, which is not allowed by the license.
If someone wants to write an Open source driver, he must make these things public. If you are resident in Germany or Europe, I'd say it's a bad idea to make such things public. If you write a closed source software, you can hide this.

The next probem is, that Siemens is constantly changing small things in the protocol. There are at least 3 protocol versions of the new protocol which are different. You must detect what Plc and what firmware you have, to check what protocol version and object model you have to use. Even the commercial 3rd party drivers like the one from Deltalogic can communicate with all versions (delta fails with 1200 fw 2).
It's not as easy as the old protocol was. With the old protocol you could write a simple driver for variable access in under 100 lines of code. With the new protocol, I'd estimate about 10k lines of code.

cardosocea said:

Do you have any experience with OPC UA and the S7-1500's?

Click to expand...

I have written my own OPC UA client driver for Android.
I do not have experience with S7-1500 but with other different OPC UA servers.
if it works with a server it should work with anyone since OPC UA is brand independent and 100% public documented.

If you want some OPC UA server for testing I have used "OPC UA ANSI C Demo Server" of unified-automation.com, it is a windows executable with simulated variables, some settings can be changed editing a XML file manually

Another possibility is to install Codesys porgramming software that also installs a PLC emulator (Soft-PLC) which has a fully functional OPC-UA server. The same happens when using a Raspberry PI as a PLC.
Also some time ago there was some public server available on the Internet but the ones I knew I think are now all down.

For me a main advantage of OPC UA is security.
Let's take an example, if a person silently connects a laptop to a switch in the industrial plant and the connected PLCs use non-secure protocols such as Modbus or Ethernet/IP or the old S7 discussed here, he can read and write variables in some PLC just knowing his IP and the address or name of the tag.

This can be completely avoided by using the OPC UA security features since it can be configured to only accept connections with a trusted certificate.

It's enough secure and encrypted to connect over the Internet without using a VPN

Thomas_v2 said:

I've decoded about 95% of the new protocol

Click to expand...

Impressive to say the least