UART-based (RS-232 and RS-485)

RS-232, formally known as Electronic Industries Alliance RS-232C, is an interface that assigns a rule for the serial interchange of binary data between a DTE (Data Terminal Equipment) and a DCE (Data Communication Equipment), even though other situations exist in which this interface is also used. 

It is designed for short distances, about 15 meters or less, and for low communication speeds, no more than 20 Kbps. In spite of this, it is very often used at higher speeds with acceptable results. It can work in asynchronous or synchronous communication mode, and in simplex, half duplex o full duplex channel multiplexation.

Configuration

The RS-232 default configuration used in EMCL-based motion controllers is shown below:

Of course, for the communication to be achieved adequately, the host application must also use this configuration. If another configuration is desired, the mentioned and other parameters can be configured through the 0x2000 - UART configuration register.

Command format

Two command and data formats are available to be used by EMCL controllers:

• ASCII format: its human-readable characteristics allow the user to communicate with Ingenia drivers through standard serial terminals.
• Binary format: its machine-to-machine characteristics allow to achieve maximum data compression and the best performance of the RS-232 interface. 

The binary format is the format used by the Ingenia software tools.

Both formats, similar to CANopen communications, contain the following information:

• Destination node identifier: It may be a value from 0-127 (both inclusive). It may be expressed in decimal or hexadecimal format (adding the prefix '0x').

Node Identifier with value '0' is considered a broadcast message. All devices connected to the communication interface will accept this message Id.

• The type of function to be carried out (FCT Field): This may be a read or write operation. When the FCT field contains a 'W' character, it will indicate that the command contains a write process. If, on the other hand, the FCT character contains an 'R,' it will indicate that the process is a read process.
• Object number: The object to work with. The object number is build with the binary combination of the SubIndex and the Index value. The SubIndex precedes the Index. It may be expressed in decimal or hexadecimal form (adding the prefix '0x')
• Object value: only necessary in write processes. The range of values accepted will depend on the object being used. It may be expressed in decimal or hexadecimal form (adding the prefix '0x').

ASCII format

(*) Only in write operations
(**) Hexadecimal code for the corresponding ASCII character.

Only node ID, object and value support hexadecimal format. Other fields do not support hexadecimal format and must be inserted as characters. In addition, the value of the command sent by the controller can be expressed in hexadecimal or decimal format. This can be configured using UART configuration object (Object 0x2000 SubIndex 4).

Example 1

The following example shows how to consult the current position (object 0x6063) of the controller with ID 2.

CODE

0x02 R 0x6063// Sent message by host
0x02 W 0x6063 0x2130 // Received message from controller

Example 2

The following example assigns value 2000 to the target position (object 0x607A) for the controller with ID 2.

CODE

2 W 0x607A 2000// Sent message by host 

Example 3

The following example assigns value 100000 to the Position control parameter set – Integral limit (Object 0x2500 SubIndex 7) for the controller with ID 12. Notice that the SubIndex is put in front of the object.

CODE

12 W 0x72500 100000// Sent message by host 

Binary format

The binary format is based on MODBUS RTU specification but, in order to achieve maximum performance, it is not fully compatible.

Binary format does not include an ACK mechanism, therefore, the Slave will not automatically reply to Write commands.

Frame codification is based on the CANopen Modbus Encapsulated Interface (MEI) type.

All the fields (except the SYNC bytes) are defined in the MODBUS specification. A brief description of each field is shown below:

• Network Address. This field is defined on the MODBUS over Serial Line. Its value is the same as Node ID.
• Function. The MODBUS function selected for all frames is the Modbus Encapsulated Interface (MEI)
• MEI type. The encapsulated protocol is the CANopen
• Protocol Control. Works like the FCT Field of the ASCII format. If the protocol control field contains a 0 value, it will indicate that the process is a read process. If the protocol control field contains a 1 value, it will indicate that the process is a write process
• Reserved Field. This byte is reserved.
• Node ID. Contains the Node ID of the controller.
• Index. Index of the object to be read or written.
• Sub-index. Subindex of the object to be read or written.
• Starting Address. Not used
• Number of data. Contains the number of data available in the data field.
• Data. Contains the object value.
• CRC. If it is available (see the description of the UART Configuration object) contains the calculated CRC.
• SYNC bytes. Four bytes with 0x55 value are sent to synchronize the communication.

More information

Further information about MODBUS and CANopen over MODBUS, please refer to these links:

• MODBUS
• CANopen over MODBUS (CiA 309-2)

When the driver Node ID is modified, all objects not saved in the non-volatile memory and from the 0x2000 address are restored to their default values. The binary mode is not saved in the non-volatile memory in order to get always an ASCII format access through any terminal software. So if the Node ID is changed using the binary mode, this will be lost and the ASCII mode will be restored.