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
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 is not possible to change dynamically the amount of transmitted data (of 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 is not possible to have, for example, two
Slave messages (two
PmaCommMsg objects) while 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 receiving the data 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:
| Baud rate | 9600 Bd |
|---|
| Number data bits | 8 |
|---|
| Parity | EVEN |
|---|
| Number of stop bits | 1 |
|---|
| Timeout between receiving 2 characters | 220 ms (ZVZ timeout according to the documentation) |
|---|
Description and recommended values for the Protocol parameters:
| High priority | Specifies 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 extension | Enable/disable automatically to generate message headers according to the RK512 extension. The headers can generate by pressing the Data setting button in 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 format | The 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 characters (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 timeout | The 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 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 header" transmission 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 header)
A lot of information can be get in the "
COMM" item of the INFO system.