PLC Header

The data-stream oriented TCP/IP protocol is capable of grouping multiple short data units into a larger unit. This increases the data throughput of the network. However, it requires a header for the protocol above TCP. This corresponds to the procedure common in other protocols (FTP, HTTP).

Only use the PLC header if the communication partner supports it. Otherwise, the connection will fail!

PLC Header Format

Byte no.	Meaning
Byte 0	0x4d ´M´
Byte 1	0x4b ´K´
Byte 2***	Number of payload bytes following the header (LSB*).
Byte 3***	Number of payload bytes following the header (MSB**).
Byte 4***	Bit 0 = 1, if other frames follow
Byte 5***	0
Byte 6***	SeqNo. LSB*
Byte 7***	SeqNo. MSB**
Datalen in bytes	Payload

*** Bytes 2 / 3, bytes 4 / 5 and bytes 6 / 7 together form the “short” data value. They are represented in the INTEL format

Acknowledges

If DataLen equals 0, the frame does not contain payload, but a life data ack. Data acknowledgments allow connection monitoring, a feature that TCP/IP, as a wide area protocol, does not include inherently. The default times for connection monitoring are the same as for the H1 protocol. This makes the S5 TCP/IP system H1-compatible from the PLC or PC perspective.

Sequence Numbers

Bytes 6 and 7 contain a sequence number that is 0 when establishing the connection and will be incremented by 1 each time payload is sent. This frame counter additionally secures the data transmission. If live data acks are sent, the sequence numbers are not incremented and Datalen is 0.

Fetch and Write Connections

For Fetch and Write jobs, the first 16 data bytes at the start of a job correspond to the SINEC AP header. The SINEC AP header is also used for H1 communication.

Sending / Receiving Data

When sending data over the S5 TCP/IP, a frame can include a maximum payload of 512 bytes. This maximum value is preset by the default tile block size. Received data packets can contain up to 1460 bytes. These limits are monitored automatically by the TCP/IP protocol so that no monitoring is required on the user side.

Transmission without Frame Header

The header at the beginning of the frame may be disabled. In this case, the application programs on both sides are responsible for monitoring. In this context, please note the following:

1. In particular with Send Direct and Receive Direct jobs, certain time limits until frame receipt must not be exceeded. If these time limit were ignored, the internal buffers would be full, e.g. due to requests. Thus, it would be impossible to synchronize request and response.

2. A certain blocked data transmission mechanism must be used so that it is possible to recognize the end of payload.

3. On the recipient side, you need to make sure that the frames from the reception buffer have been read before the partner station sends the next frame.