Promotic

Pm3964 - Driver for communication with SIMATIC PLC devices by 3964, 3964R or RK-512 protocol

Before using this driver in the PROMOTIC application it is highly recommended to watch "PROMOTIC video tutorial 4 - Communication drivers".

Basic properties of the driver:
- Usage of this driver requires purchase of the Pm3964 licence. When developing the application in the freeware mode PmFree, or with development environment and while testing it in runtime, this component is always functional.
- The communication is done for serial link (COM1, COM2 ...).
- This is a point-to-point communication type, it means that one PmaComm object can communicate only with one device (the protocol does not support multiple device adressing).
- The driver is incorporated into the PROMOTIC system by means of the PmaComm object.
The driver supports the usage of the PmaCommMsg object. The PmaCommGroup object cannot be used.
For easy integration of this driver into the application it is handy to use: Preconfigurations in group "3964 and RK512"


The 3964 is a communication protocol that serves for the connection of two devices. This protocol is of the Master-Slave type (it means that both devices can alternate in the communication supervision). In the PROMOTIC system this driver is implemented in such way that there can be more PmaCommMsg objects of the Master type (see the "Message type" configurator) but only one object of the Slave type.

Notes for communication of the Slave type in the PROMOTIC system:
The Slave message is that that waits at first for the data receipt from the Master and then it replies. It means that the Master specifies when the transfer occurs. Because it isn't possible to change dynamically the amount of transmitted (received) data in the PROMOTIC system objects, the object of the Slave type serves only for the receipt and transmission of the same type of data. It isn't possible to have, for example, two Slave messages (two PmaCommMsg objects) while the first one only receives the data and the other should send the data.
For the correct response to the Slave message it is usually necessary to use the onDataReceive event that is triggered after the data receipt but before sending the response. You can find in this event (from variables on the "Data-received" tab) how the response should be and accordingly to set the data on the "Data-sent" tab.

The K3964(R) protocol is used by many technological devices as for example:
- SIMATIC - The SIEMENS company (either it has already build it up or the CP525 communication card can be used)
- INTECONT - The SCHENCK company


Recommended values of the PmaComm object parameters:

Recommended values for the Serial link parameters:
Baud rate9600 Bd
Number data bits8
ParityEVEN
Number of stop bits1
Timeout between receiving 2 characters220 ms (ZVZ timeout according to the documentation)
Description and recommended values for the Protocol parameters:
High prioritySpecifies whether the station has the higher priority than the opposite station. At the opposite station it is necessary to set the reverse priority. Setting this option correctly limits possible conflicts on the line.
With RK512 extensionEnable/disable automatically to generate message headers according to the RK512 extension. The headers can generate by pressing the Data setting button in the parameters of the communication message. A detailed description of the headers is stated further in the "Communication with RK512 extension" section.
Use checksum (3964R)Specifies whether the protocol contains the checksum. If the checksum is enabled, then there is included the XOR checksum in the protocol. It goes about the 3964R protocol.
Data formatThe Simatic device has stored bytes of the Integer data type in the reverse order and the Short data type type in different format of the real number than the standard on the computer. That's why the driver converts these values.
If the PC option is selected, then the conversion isn't performed. It is necessary, for example, for the communication with the SCHENCK scale where the format is like on the computer.
Maximum message size [in bytes]Specifies the maximum number of bytes in the message (received or transmitted) without check chars (i.e. max. data size that is configured on the Data-sent or Data-received tabs).
Confirmation timeout after STX [ms]Specifies the timeout between sending the STX signal and receiving the DLE signal. It is so-called QVZ timeout and default setting is 2000 or 550 ms (depends on the documentation).
Confirmation timeout after ETX [ms]Specifies the timeout between sending and receiving the DLE signal. It should be the same as the "Confirmation timeout after STX" by default.
Response receipt timeoutThe time (in milliseconds) the driver is waiting for the response on sending the message.
If no response comes during this time, then the transmission of the message is terminated (the onEndOfTransfer event is triggered with error 24 or 66). It is timeout between receiving the DLE after sending the message and receiving the STX. It should be the same as the "Confirmation timeout after STX" by default.

Communication without RK512 extension

The communication type without the RK512 extension (i.e. pure 3964 protocol) is significantly limited as for the universality of the data transfer. It is possible to send and receive only standalone data without the address specification. The message of the Master type is therefore designed only for sending the data and therefore only the "Data-sent" tab should be filled in. The message of the Slave type is designed only for receiving the data and therefore only the "Data-received" tab should be filled in. Both tabs are filled in only with the data to be transferred.
Because only the currently transferred data is defined on the data tabs, depending only on the current application, the "Data setting" button is not available and the designer must fill in these data into the tabs manualy.

Communication with RK512 extension

RK512 headers description:
Some devices transferring messages by the 3964 protocol send a message header before the "useful" data. The header has got the standard format. Further described headers can be created automatically by the "Data setting" button in the PmaCommMsg object. To allow an access to the "Data setting" button, the RK512 extension must be enabled in the protocol parameters. This extension distinguishes 2 types of standardized headers. The long header is transmitted by messages of the Master type; its receipt is expected by messages of the Slave type. On the other hand the short header is transmitted by messages of the Slave type as a response, its receipt is expected by messages of the Master type.

The long header contains the following items (all are of the Byte type):
0 - Tg1: (Telegrammkennung) 0 by default. If there is the value of 255, then it means that the message is the continuance of the previous message and in this case the header consists only of the first four items (thus it is necessary to use so-called "short header" - see further).
1 - Tg2: (Telegrammkennung) 0 by default.
2 - Cmd: Command. Asc("A") or Asc("O") = SEND, Asc("E") = FETCH. If we send data to the other side (SEND), then set 'A' or 'O' here. If we require data from the other side (FETCH), then set 'E' here.
3 - CmdTyp: Command type, for example Asc('D')=data block. It holds the following values by default:
'D' - (Datenbaustein) data block (the most used)
'X' - (erweiterter Daten) extended DB block
'E' - (Eingangsbytes) input data
'A' - (Ausgangsbytes) output data
'M' - (Merkerbytes) marks
'Z' - (Zahlerzellen) counter
'T' - (Zeitzellen) timer
'S' - (absolute Adressen) absolute address
'B' - (Systemadressen) system address
'P' - (Peripheriebytes) interface data
'Q' - (erweiterte Peripherie) extended interface
4 - Addr1: The destination address (for the SEND) or the source address (for the FETCH) of the data. The most often there is the data block number here - "DB_Nr. high".
5 - Addr2: Data address. There is 0 or an offset here. The most often there is "DW_Nr. low" here.
6 - Ndat1: Upper byte of the number of transmitted data. Practically there is always 0.
7 - Ndat2: Lower byte of the number of transmitted data. The number of transmitted data is specifies in bytes or words.
8 - Koord: There is the value 255 here usually. Otherwise it is the number of bytes with coordination marks.
9 - KooCPU: There is the value 255 here usually. Otherwise:
bit 0-3 = number of bits with coordination marks, otherwise 16
bit 4-7 = CPU number


The short head contains the following items (all are of the Byte type):
Tg1: (Telegrammkennung) 0 by default. If there is the value of 255, then it means that the message is the continuance of the previous message.
Tg2: (Telegrammkennung) 0 by default.
Cmd: Value 0.
Fn: Error number (Fehlernummer des Partners)


The example of the message configuration for the RK512 extension:
The message of the Master type that writes 3 words to the offsets DW4 to DW6 into the data block 61, i.e. DB61:
There are following variables on the "Data-sent" tab:
Tg1 = 0
Tg2 = 0
Cmd = Asc("A")
CmdTyp = Asc("D")
Addr1 = 61
Addr2 = 4 (1.transmitted word is DW4)
Ndat1 = 0
Ndat2 = 3 (we transmit 3 words)
Koord = 255
KooCPU = 255
DW4 = 1 (Content of the 1.transmitted word, Integer data type)
DW5 = 2 (Content of the 2.transmitted word, Integer data type)
DW6 = 3 (Content of the 3.transmitted word, Integer data type)

There are following variables on the "Data-received" tab:
Tg1 = 0
Tg2 = 0
Cmd = 0
Fn = 0

Other informations

Simplified description of the communication process:
The following description has only an informative character and the designer needn't know this information. It goes about the shorten description of how the physical transmission proceeds on the line.
The knowledge can help for the INFO system viewing: "COMM/Pm3964" item, the "Monitor" tab.
Let's presume that we want to send data (n bytes) of the "without the header" transmission type (in case of the "with the header" transmissionn type the header would be considered as ordinary data). In this case the transmission proceeds as follows:

- STX ------> send the STX character (02hexa)
- <------ DLE receive the response by the DLE character (10hexa)
- 1.byte ------> send the data themselves
- 2.byte ------>
- ...
- n.byte ------>
- DLE ------> send the DLE character (10hexa)
- ETX ------> send the ETX character (03hexa)
- BCC ------> send the checksum (only for 3964R protocol)
- <------ DLE receive the response by the DLE character (10hexa)
 
The receipt of the DLE character means the positive response in this case. If the NAK character (15hex) comes, then it means the negative response and the transmission of the message is repeated. The receipt process of the message turns precisely inside out.

Troubleshooting:
The most often defects on the first tests of the communication are in bad connection of communication cables. If the cable is OK but the communication still is not functional, then it is necessary to focus on the software settings, for example:
- Check the communication parameters (transfer rate, data length, parity, number of stop-bits)
- Find out if the transmission type is with or without the header
- Check if the values of the header are set correctly (if case of the transmission type with the header)

A lot of information can be get in the "COMM" item of the INFO system.
PROMOTIC 9.0.27 SCADA system documentation MICROSYS, spol. s r.o.

Send page remarkContact responsible person
© MICROSYS, spol. s r.o.