Promotic
WikipediaLinkedInYoutubeTwitterFacebook

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

Before using this driver in the PROMOTIC application it is highly recommended to read the chapter: Communicaton using the PROMOTIC drivers.
 
Basic properties of the driver:
- Using this driver is bound to purchase the license: Pm3964. With the freeware version PmFree, or when developing the application (with development environment for tersting purposes), this component is always functional.
- The communication is done via standard serial link (COM1, COM2 ...).
- This is a point-to-point communication type, i.e. one PmComm 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 PmComm object.

Driver supports to usage of PmCommMsg object. The PmCommData object cannot be used.

For easy integration of this driver into the application it is handy to use: Preconfigurations in group "3964 and RK512 protocol"

 
The 3964 is a communication protocol that serves for the connection of two devices. This protocol is of the Master-Slave type, which 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 PmCommMsg objects of the MASTER type (see the configurator "Message type") but ONLY ONE object of the SLAVE type.
 
Notes to the communication of the SLAVE type within the PROMOTIC system:

The Slave message is that that waits at first for the data receipt from the MASTER and then it replies. This means that the MASTER determines when the transfer occurs. As 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 PmCommMsg 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 mostly necessary to use the onDataReceive event that fires AFTER the data receipt but BEFORE sending the response. You can find in this event (from data of the Data-received page) how the response should be and accordingly to set the data on the Data-sent page.

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

Recommended parameters values:

Recommended values for the Serial link parameters:
Baud rate9600 Bd
Number of data bits8
ParityEVEN
Number of stop bits1
Timeout between receiving 2 chars220 ms (ZVZ timeout according to the documentation)
Description and recommended values for the Protocol parameters:
High priority option determines if the station has the higher priority than the opposite station. At the opposite station it is then necessary to set the reverse priority. Setting this option correctly limits possible conflicts on the line.
With RK512 extensionenables automatically to generate message headers according to the RK512 extension. Pressing the "Data setings" button in the parameters of the communication message can generate the headers. A detailed description of the headers is stated further in the "Communication with RK512 extension" section.
Use check sum (3964R)determines if the protocol contains the check sum. If the check sum is enabled, there is included the XOR check sum in the protocol. It goes about the common used protocol 3964R.
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 PC standard. That's why the driver converts these values.

If the PC option is selected, the conversion isn't performed. It is necessary, for example, for the communication with the SCHENCK scale where the format is like on PC.

Maximum message size [byte]defines the maximum number of bytes in the message (received or transmitted) without check chars (i.e. maximum data size that is configured on the Data-sent or Data-received pages).
Acknowledgement timeout after STX [ms]defines the timeout between sending the STX signal and receiving the DLE signal. It is so called QVZ timeout and default settings are 2000 or 550 ms (depends on the documentation).
Acknowledgement timeout after ETX [ms]defines the timeout between sending and receiving the DLE signal. It should be the same as the "Acknowledgement timeout after STX [ms]" 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, the transfer of the message is terminated (event onEndOfTransfer fires 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 "Acknowledgement timeout after STX [ms]" 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 so only the Data-sent page should be filled in. The message of the Slave type is designed only for receiving the data and so only the Data-received page should be filled in. Both data pages are filled in only with the data to be transfered.

Because only the currently transfered data is defined on the data pages, depending only on the current application, the "Data setings" button is not available and the designer must fill in these data into the pages 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 setings" button in the PmCommMsg object. To allow an access to the "Data setings" 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), we set 'A' or 'O' here. If we require data from the other side (FETCH), 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 stated in bytes or words.
8 - Koord: There is the value 255 here. Otherwise it is the number of bytes with coordination marks.
9 - KooCPU: There is the value 255 here. Otherwise:
0.to 3.bit = number of bits with coordination marks, otherwise 16
4.to 7.bit = 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)
 
An 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, which means DB61:

There are following variables on the Data-sent page:

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 type)
DW5 = 2 (Content of the 2.transmitted word, Integer type)
DW6 = 3 (Content of the 3.transmitted word, Integer type)

There are following variables on the Data-received page:

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 user of the 3964 protocol 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, "Monitor" page.

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" transmission type the header would be considered as ordinary data). Then 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 check sum (only for the 3964R protocol)
- <------ DLE receive the response by the DLE character (10hexa)

The receipt of the DLE signal means the positive response in this case. If the NAK signal (15hex) comes, 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 doesn't work properly, it is necessary to focus on the software settings, for example:

- check the communication parameters (baud speed 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 from the INFO system in the COMM item.

© MICROSYS, spol. s r. o.Tavičská 845/21 703 00 Ostrava-Vítkovice