Siemens communications overview

 

Snap7, by design, only handles Ethernet S7 Protocol communications.

Why only Ethernet ?

Having said that we are not talking about the fieldbus, but we are focusing on PC-PLC communications, Ethernet has several advantages against Profibus/Mpi :

·         It’s faster, CP 1543-1 (for the newborn S71500) has a bandwidth of 1000 Mbps.

·         It's more simply to troubleshoot, in 50% of cases a "ping" is good enough to solve your problems.

·         It’s cheaper, you don’t need a special adapter to communicate (which, moreover, cannot not be used with any hardware and any virtual infrastructure as Snap7 does).

·         If you use Snap7Server, many more non-Siemens panels/scada can be connected with your software.

 

Siemens PLCs, through their communication processors (CP) can communicate in Ethernet via two protocols:

Open TCP/IP and S7 Protocol.

The first is a standard implementation of the TCP/IP protocol, it's provided mainly to connect PLCs with non-Siemens hardware.

TCP/IP is a generic protocol, it only states how the packets must be transferred, and it doesn't know anything about their content.

Finally, TCP/IP is stream oriented (though Siemens FC/FB needs to packetize the data stream into blocks).

As said, it is a standard, so you don’t need of Snap7 to use it, your preferred socket libraries are perfectly suitable.

S7 Protocol

 

S7 Protocol, is the backbone of the Siemens communications, its Ethernet implementation relies on ISO TCP (RFC1006) which, by design, is block oriented.

 

Each block is named PDU (Protocol Data Unit), its maximum length depends on the CP and is negotiated during the connection.

S7 Protocol is Function oriented or Command oriented, i.e. each transmission contains a command or a reply to it.

If the size of a command doesn't fit in a PDU, then it must be split across more subsequent PDU.

 

Each command consists of

·         A header.

·         A set of parameters.

·         A parameters data.

·         A data block.

 

The first two elements are always present, the other are optional.

 

To understand:

Write this data into DB 10 starting from the offset 4.

Is a command.

Write, DB, 10, 4 and data are the components of the command and are formatted in a message in accord to the protocol specifications.

S7 Protocol, ISO TCP and TCP/IP follow the well-known encapsulation rule : every telegram is the "payload" part of the underlying protocol.

 

 

S7 Commands are divided into categories:

Ø  Data Read/Write

Ø  Cyclic Data Read/Write

Ø  Directory info

Ø  System Info

Ø  Blocks move

Ø  PLC Control

Ø  Date and Time

Ø  Security

Ø  Programming

For a detailed description of their behavior, look at the functions list of Snap7Client that are arranged in the same way (Except for Cyclic Data I/O and Programming which are not implemented).

Siemens provides a lot of FB/FC (PLC side), Simatic NET software (PC side) and a huge excellent documentation about their use, but no internal protocol specifications.

 

The Siemens theatre

 

In the Siemens communication theatre there are three actors:

1.   The Client

2.   The Server

3.   The Partner (a.k.a. the peer in the classic computer dictionary).

And as in all good theater companies, they follow their script:

o   The client can only query.

o   The server can only reply.

o   The partners can speak both on their own initiative.

 

 

All three components on the left are Clients, they connect to the internal server of the Communication Processor (CP), and make an S7 Request.

The server replies with a S7 answer telegram.

 

No configuration is needed server side. The server service is automatically handled by the firmware of the CP.

 

The CP can be external such as CP343/CP443 or internal in 3XX-PN or 4XX-PN CPUs, they, however, work in the same way.

 

 

 

 

Also a PLC can work as Client, in this case the data read/write requests are made via FB14/FB15 (Get/Put), and a S7 connection, created with NetPRO, is needed.

 

 

 

The Partners can exchange unsolicited data, i.e. once the connection is established, both can send data to the other partner.

This kind of communication often is named Client-Client by Siemens in their manuals.

The peer that requests the connection is named Active Partner, the peer that accepts the connection is named Passive partner.

The communication is performed via FB12/FB13 (S7300) or SFB12/SFB13 (S7400), their symbolic names are BSend/BRecv (Block Send / Block Recv).

An important remark is that : when PLC A calls BSend, BRecv must being call in PLC B in the same time, to complete the transaction.

 

For both partners an S7 Connection must be created with NetPro.
The Active partner must have the “Establish an active connection” option checked in the connection properties (You can find further details into the Snap7Partner description).

 

This kind of communication model is provided mainly to connect PLCs each other, Snap7Partner however, allows your software to act as active or passive partner in a PLCs network.