Serial communication. RS-232 and RS-485 protocols |
All the Technosoft drives/motors can communicate via RS-232. Some of them also accept RS-485 as a substitute for RS-232. In the following paragraphs, the terminology serial communication refers to the features common to both RS-232 and RS-485. The terminology RS-232 communication or RS-485 communication is used to features that are specific for one or the other. The RS-232 communication is point-to point, full duplex, and enables you to link 2 devices. A typical example is when you connect your PC with a Technosoft drive/motor. Use the RS-232 communication if you want to:
In cases c) and d), the Technosoft drive/motor connected to the host acts as a relay axis (see Communication protocols overview for details).
The RS-485 communication is multi-point, half duplex, and enables you to link up to 32 drives/motors in a network. In an RS-485 network, at one moment only one device is allowed to send data. If two devices start by mistake to transmit in the same time, both transmissions are corrupted. Therefore for a correct operation, in an RS-485 network it is mandatory to have a master, which controls the transmission. Put in other words, only the master can initiate a transmission, while all the other devices from the network may transmit only when the master asks them to provide some data. Normally you should set as master your host. Use the RS-485 communication if you want to:
Remark: If the absence of a host, you can use any drive as master to control the RS-485 communication. This is possible due to the powerful set of TML commands for multiple axes (see Motion – Data Transfer Between Axes)
The Technosoft drives communicate serially using 8 data bits, 2 stop bits, no parity at the following baud rates: 9600 (default after reset), 19200, 38400, 56600 and 115200. The messages exchanged through serial communication are encapsulated in the following format: Serial message structure – TML Instruction encapsulation The message length byte contains the total number of bytes of the message minus 2. Put in other words, the length byte value is the number of bytes of the: Axis/group ID Code (2bytes), the Operation Code (2 bytes) and the Data words (variable from 0 to 8 bytes). The Checksum byte is the sum modulo 256 of all the bytes of the message except the checksum byte itself.
Message types on serial communication The serial communication protocol is based on 3 types of messages imposed by the nature of the TML commands encapsulated:
The next paragraphs present an example of each message type.
Example 1 – Type A Message: A host is connected to a drive/motor via RS-232 and sends the TML instruction “KPP = 5” (set proportional part of the position controller with value 5). The axis ID of host and of the drive/motor are 255 = 0FFh. The Axis ID code and the TML instruction binary code are: Axis ID code + Binary code of TML Instruction KPP = 5 sent to axis 255 Remark: Use Binary Code Viewer to get the binary code of TML instructions The host must send a serial message with the following contents: Serial message: TML Instruction KPP = 5 sent to axis 255 The drive/motor will return a byte 0x4F as confirmation that the message was received OK. (See below the RS-232 and RS-485 protocols description for details) Remarks:
Example 2 – Type B Message: A host is connected to a drive via RS-232 and wants to get the value of the KPP (proportional term of the position controller) parameter from the drive. KPP address in TML data memory is 025Eh. The ID of the host and the drive/motor are 255 = 0FFh. The host sends a “GiveMeData” request and the drive/motor answers with a “TakeData” message. Let’s suppose that the KPP value returned by the drive/motor is 288 (120h). Remark: Use Command Interpreter to get TML data addresses. A “GiveMeData” request message for a TML data includes the following information: “GiveMeData” request for a TML data – Message description The “TakeData” answer message includes the following information: “TakeData” answer - Message description In the particular case of this example, the axis ID code and the binary code of “GiveMeData” are: Axis ID code + Binary code of “GiveMeData” request for KPP value sent to axis 255 The axis ID code and the binary code of ”TakeData” are: Axis ID Code + Binary code of “TakeData” with KPP value from axis 255 The host must send a “GiveMeData” request message with the following contents: Serial message: “GiveMeData” request for KPP value sent to axis 255 The drive/motor will return a byte 0x4F as confirmation that the message was received OK (See below the RS-232 and RS-485 protocols description for details), then the “TakeData” answer message with the following contents: Serial message: “TakeData” with KPP value from axis 255 Remarks:
Example 3 – Type C Message: A host is connected to a drive via RS-232 and wants to be informed when the programmed motion is completed. The axis ID of the host and the drive/motor are 255 = 0FFh. A Type C message is a “TakeData2” message sent without a “GiveMeData2” request. It includes the following information: “TakeData2” - Message description The destination axis is provided by the TML variable MASTERID, according with formula: MASTERID = host axis ID * 16 + 1. In this example, the 8-bit host axis ID = 255, hence MASTERID = 16 * 255 + 1 = 4081 (0xFF1). In the case of a Type C message, the “TakeData2” can return:
Remark: Use Command Interpreter to get the addresses for the above TML data. Note that the SRL and SRH status registers may also be accessed as a single 32-bit variable named SR32. The bit selection is done via 3 masks, one for each register, set in TML parameters: SRL_MASK, SRH_MASK, MER_MASK. A bit set in a mask, enables a message transmission when the same bit from the corresponding register changes. In this example, the motion complete condition is signaled by setting SRL.10 = 1. To activate automatic sending of a “TakeData2” whenever SRL.10 changes, set SRL_MASK = 0x0400. If SRH = 0x201 and SRL = 0x8400, after SRL.10 goes from 0 to 1, the host gets a “TakeData2” message with the following contents: Serial message: “TakeData2” with status registers SRL and SRH from axis 255 Remark: A “TakeData2” message with SRL.10=1 signals that the last programmed motion is completed. A “TakeData2” message with SRL.10=0 signals that a new motion has started and may be used as a confirmation for the last motion command.
RS-232 communication protocol
The RS-232 protocol is full duplex, allowing simultaneous transmission in both directions. After each command (Type A or B) sent by the host, the drive will confirm the reception by sending one acknowledge-Ok byte. This byte is: ‘O’ (ASCII code of capital letter “o”, 0x4F). If the host receives the ‘O’ byte, this means that the drive has received correctly (checksum verification was passed) the last message sent, and now is ready to receive the next message. Remark: If the destination axis for the message is not the axis connected with the host via RS-232 (e.g. the relay axis), but another axis connected with the relay axis via CAN-bus, the reception of the acknowledge-Ok byte from the relay axis doesn’t mean that the message was received by the destination axis, but just by the relay axis. Depending on the CAN-bus baud rate and the amount of traffic on this bus, the host may need to consider introducing a delay before sending the next message to an axis connected on the CAN-bus. This delay must provide the relay axis the time necessary to retransmit the message via CAN-bus. If any error occurs during the message reception, for example the checksum computed by the drive axis doesn’t match with the one sent by the host, the drive will not send the acknowledge-Ok byte. If the host doesn’t receive any acknowledge byte for at least 2ms after the end of the checksum byte transmission, this means that at some point during the last message transmission, one byte was lost and the synchronization between the host and the relay axis is gone. In order to restore the synchronization the host should do the following:
When a host sends a type A message through RS-232 it has to:
When a host sends a type B message through RS-232 it has to:
When the relay axis returns an answer message it doesn’t expect to receive an acknowledge byte from the host. It is the host task to monitor the communication. If the host gets the response message with a wrong checksum, it is the host duty to send again the data request.
RS-485 communication protocol
The RS-485 protocol is half duplex. If two devices start by mistake to transmit in the same time, both transmissions are corrupted. Therefore for a correct operation, in an RS-485 network it is mandatory to have a master, which controls the transmission. This means that only the master can initiate a transmission, while all the other devices from the network may transmit only when the master asks them to provide some data. Usually you should set as master your host. After each command (Type A or B) sent by the host to one drive, the drive will confirm the reception by sending one acknowledge-Ok byte. This byte is: ‘O’ (ASCII code of capital letter “o”, 0x4F). If the host receives the ‘O’ byte, this means that the drive has received correctly (checksum verification was passed) the last message sent, and now is ready to receive the next message. The acknowledge-Ok byte is not sent when the host broadcasts a message to a group of drives. If any error occurs during the message reception, for example if the checksum computed by the drive axis doesn’t match with the one sent by the host, the drive will not send the acknowledge-Ok byte. If the host doesn’t receive any acknowledge byte for at least 2ms after the end of the checksum byte transmission, this means that at some point during the last message transmission, one byte was lost and the synchronization between the host and the relay axis is gone. In order to restore the synchronization the host should do the following:
When a host sends a type A message through RS-485 it has to:
When a host sends a type B message through RS-485 it has to:
Remarks:
When a drive returns an answer message it doesn’t expect to receive an acknowledge byte from the host. It is the host task to monitor the communication. If the host gets the response message with a wrong checksum, it is the host duty to send again the data request. See also: Communication protocols – Overview CAN-bus communication. TMLCAN protocol |