Description of the protocols

The 3964 and 3964R procedures, plus the RK512 computer protocol which is based on these, specify data traffic over a serial interface that can be used, for instance, to control a Simatic S5 device. The 3964 procedure defines how a data block is transferred, i.e. handshaking procedures, and also the mechanisms for safeguarding data integrity. The 3964R procedure differs from the 3964 simply by a longer acknowledge delay time and the omission of a checksum. The RK512 computer protocol is based on this procedure, and defines the structure of the messages in which the data and commands are sent.

3964 (R) procedure

Data transfer is asynchronous either via a V24 interface or a 20 mA current loop. The baud rate can lie between 110 and 9600 baud, the data format is 8E1.

The STX character is used for handshaking, and must either be accepted with DLE or rejected with NAK by the opposite end within the acknowledgement delay time (QVZ) of 2 s (550 ms for the 3964 procedure). If the connection is rejected, up to six more attempts are made before an error is signaled to the next layer up. The end of the data block is indicated by the DLE ETX characters. The 3964R procedure attaches an extra checksum BCC to these, formed by exclusive-ORing all data bytes including the DLE-ETX flag. Each item of data must follow within a character delay time (ZVZ) of 220ms. The opposite end confirms receipt with DLE, or with NAK if errors have been detected.

Table: Data traffic in the 3964R procedure.

Sender STX Data block DLE ETX BCC
Receiver DLE DLE

If the sender receives a NAK during transfer it aborts the procedure and makes a new attempt.

There is an initialization conflict if the opposite end responds to a send attempt with STX as well. This is solved by assigning priorities. There are just two levels: high or low priority. The end with low priority must then accept the send request with DLE.

RK512 computer protocol

The RK512 computer protocol is based on the 3964 or 3964R procedure, and defines the message traffic. RK512 distinguishes between command, acknowledgement and follow-on messages. Command messages initiate message traffic and contain a SEND or FETCH command with which data is transferred. Acknowledgement messages respond to the command telegrams and contain any data that may have been requested. If the command cannot be executed, the acknowledgement message contains an appropriate error code. Up to 128 bytes can be contained in one message. If more data needs to be transferred then follow-on messages are necessary.

The message traffic is half-duplex, which means that before the opposite end has acknowledged a message, it can itself send a command message first. No message can be sent, however, while the opposite end is still sending, and neither can a further command message can be sent before an existing one is acknowledged.

Table: Basic structure of a command message.

1 2 3 4 5 6 7 8 9 10
00h 00h high low high low
Command Type Address Data length CPU No / CF

Table: Basic structure of a follow-on message.

1 2 3 4
FFh 00h
Command

Table: Basic structure of an acknowledgement message.

1 2 3 4
00h 00h 00h
(FFh) Error

The first byte in the message header is a message identifier. This is 00h for the first command message, and FFh for a follow-on message. Acknowledgement messages repeat this identifier. In command and follow-on messages the third byte specifies whether it is a SEND or FETCH message, and the fourth byte defines the data block type.

Command messages contain the address in the fifth and sixth bytes, and the data length in words or bytes in the seventh and eighth bytes. A CPU number and a coordination flag can be specified in the last two bytes.

Acknowledgement messages contain an error code in the fourth byte. If the command has been successfully processed this code is 0, otherwise it provides information on the type of error.

Any data that may need to be transferred follows immediately after the message header.