For easy integration of this driver into the application it is handy to use: Preconfigurations in group "3964 and RK512 protocol"
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.
|Baud rate||9600 Bd|
|Number of data bits||8|
|Number of stop bits||1|
|Timeout between receiving 2 chars||220 ms (ZVZ timeout according to the documentation)|
|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 extension||enables 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 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 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 timeout||The 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.|
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.
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 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:
There are following variables on the Data-received page:
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:
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.
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:
A lot of information can be get from the INFO system in the COMM item.