Master Ethernet controllers can communicate with the RMC using several methods. This topic describes only one of those methods—using raw UDP packets—which is appropriate when the master controller cannot use any of the other methods. Please review the other available options in the Ethernet Overview topic before proceeding with this method.
This topic assumes that your controller has an established network platform and that you are familiar with how to send and receive UDP packets on that platform. Some PLCs provide access to UDP packets using function blocks, while embedded controllers may require using a socket interface such as Berkeley sockets. Proper use of these interfaces is outside the scope of this documentation.
Protocol Overview
The simplest UDP-based protocol supported by the RMC is the Delta Motion Control Protocol (DMCP). This topic describes how to form DMCP packets to communicate with the RMC75E, RMC150E, and RMC200. The RMC listens for DMCP requests on UDP port 1324. The client port number can be any number. This protocol is a request/response protocol, meaning that for each request packet sent to the RMC, there will be one response packet sent by the RMC.
Delta has an example C code implementation of DMCP on it's forum: https://forum.deltamotion.com/
For RMC75E and RMC150E firmware versions prior to 3.31.0, Delta recommended using the FINS/UDP protocol for direct communication over UDP. For details, see the FINS/UDP topic.
Writing Data to the RMC
To send one or more registers to the RMC, send the following packet to the RMC:
|
Offset |
Data (hex) |
Description |
|
0-1 |
nn nn |
Packet Length. Indicates the total length in bytes of this packet, excluding this 2-byte field. This 16-bit value is encoded with the least significant byte first. |
|
2-3 |
00 02 |
Static Values. These bytes must always hold these values. |
|
4-5 |
nn nn |
Transaction ID. This value is simply echoed by the RMC in its response packet. It can be used to match responses with requests, since UDP does not prevent packets from being delivered out-of-order or dropped. |
|
6 |
15 |
Function Code. This byte must be 15 in a write request. |
|
7 |
nn |
Byte Order. Determines the byte order for all following fields. Notice that the Packet Length byte order is not affected by this field.
|
|
8-9 |
nn nn |
Starting Address (File). Gives the file number for the address (f in the IEC address format %MDf.e) to start the write at. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
|
10-11 |
nn nn |
Starting Address (Element). Gives the element number (e) for the address (%MDf.e) to start the write at. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
|
12-13 |
nn nn |
Write Count. The number of 32-bit registers to write. This value must be between 0 and 256. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
|
14-15 |
00 00 |
Reserved. Must be zero. |
|
16-… |
… |
Data. The values of each register to write should follow the above header. Each 32-bit value is encoded in either LSB- or MSB-first byte order, as determined by the Byte Order field. For LSB-first byte order, the value 16#11223344 should be encoded as 44 33 22 11. For MSB-first byte order, this would be encoded as 11 22 33 44. |
The RMC will respond to this request with the following packet:
|
Offset |
Data (hex) |
Description |
|
0-1 |
06 00 |
Packet Length. Indicates the total length in bytes of this packet, excluding this 2-byte field. This 16-bit value is encoded with the least significant byte first. |
|
2-3 |
00 02 |
Static Values. These bytes will always have these values in the response. |
|
4-5 |
nn nn |
Transaction ID. This value will echo the Transaction ID in the request. It should be used to match this response to the corresponding request. |
|
6 |
95 -or- 55 |
Function Code (Response). If the write was processed successfully, this byte will be 95, otherwise it will hold 55. |
|
7 |
nn |
Response Code. Indicates whether the write was successful or not. See the DMCP Response Codes section below. |
Reading Data from the RMC:
To read one or more registers from the RMC, send the following request packet to the RMC:
|
Offset |
Data (hex) |
Description |
|
0-1 |
0C 00 |
Packet Length. Indicates the total length in bytes of this packet, excluding this 2-byte field. This 16-bit value is encoded with the least significant byte first. |
|
2-3 |
00 02 |
Static Values. These bytes must always hold these values. |
|
4-5 |
nn nn |
Transaction ID. This value is simply echoed by the RMC in its response packet. It can be used to match responses with requests, since UDP does not prevent packets from being delivered out-of-order or dropped. |
|
6 |
14 |
Function Code. This byte must be 14 in a read request. |
|
7 |
nn |
Byte Order. Determines the byte order for the Starting Address fields, the Read Count field, and the Data registers in the response. Notice that the Packet Length byte order is not affected by this field.
|
|
8-9 |
nn nn |
Starting Address (File). Gives the file number for the address (f in the IEC address format %MDf.e) to start the read at. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
|
10-11 |
nn nn |
Starting Address (Element). Gives the element number (e) for the address (%MDf.e) to start the read at. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
|
12-13 |
nn nn |
Read Count. The number of 32-bit registers to read. This value must be between 0 and 256. The order of the bytes in this 16-bit value is determined by the Byte Order field. |
The RMC will respond to this request with the following packet:
|
Offset |
Data (hex) |
Description |
|
0-1 |
nn nn |
Packet Length. Indicates the total length in bytes of this packet, excluding this 2-byte field. This 16-bit value is encoded with the least significant byte first. |
|
2-3 |
00 02 |
Static Values. These bytes will always have these values in the response. |
|
4-5 |
nn nn |
Transaction ID. This value will echo the Transaction ID in the request. It should be used to match this response to the corresponding request. |
|
6 |
94 -or- 54 |
Function Code (Response). If the read was processed successfully, this byte will be 94, otherwise it will hold 54. |
|
7 |
nn |
Response Code. Indicates whether the read was successful or not. See the DMCP Response Codes section below. |
|
8-… |
… |
Data. The values of each register that was read will follow the above header. Each 32-bit value is encoded in either LSB- or MSB-first byte order, as determined by the Byte Order field. For LSB-first byte order, the value 16#11223344 will be encoded as 44 33 22 11. For MSB-first byte order, this will be encoded as 11 22 33 44. |
Register Addresses
This protocol uses the same two-level file/element addressing format as the RMC IEC addressing. The IEC Addressing topic describes how this addressing format works.
DMCP Response Codes
The response packet holds a single-byte Response Code field, indicating to the client whether the transaction was successful or not. Notice that the Response Function Code byte will also indicate whether the Response Code is 00 (success) or not. If the Response Code is 00, then the Response Function Code will match the request’s Function Code plus 0x80. Otherwise, the Response Function Code will match the request’s Function Code plus 0x40.
|
Response Code |
Description |
|
00 |
Success. |
|
01 |
Malformed. |
|
02 |
Too Long. |
|
03 |
Invalid Address. |
Notice that in certain other error cases, the RMC will not generate a response to the DMCP request. Such cases include the following:
UDP datagram is less than 7 bytes in length.
UDP datagram size does not match the Packet Length field. The UDP datagram length must always be 2 bytes longer than the Packet Length field.
The Static Values (bytes 2-3) are not 00 and 02 respectively.
Unsupported Function Code.
Example 1: Writing a Single Register
In this example, the client will write the value 0x11223344 to variable 0 (%MD56.0), using the LSB-first byte order (00). The client chooses a Transaction ID of 00 00 for this packet, either because he is not using this field, or because this is the first transaction.
Plugging in the above values in the proper byte order gives us the following packet that should be sent to UDP port 1324 on the RMC:
12 00 00 02 00 00
15 00
38 00 00 00 01 00 00 00
44 33 22 11
After the RMC has successfully received and processed this write request, it will respond with the following packet:
06 00 00 02 00 00 95 00
Notice that the last byte is the Response Code, with 00 meaning success.
Example 2: Reading a Single Register
In this example, the client will read a value from variable 0 (%MD56.0). The client chooses a Transaction ID of 0x0001, perhaps because this is the second transaction.
Plugging in the above values in the proper byte order gives us the following packet that should be sent to UDP port 1324 on the RMC:
0C 00 00 02 01 00
14 00
38 00 00 00 01 00
After the RMC has successfully received and processed this write request, it will respond with the following packet if variable 0 held the value 0x11223344:
0A 00 00 02 01 00
94 00
44 33 22 11
Notice that byte 7 holds the Response Code, and bytes 8-11 hold the data that was read.
See Also
IEC Addressing | Communicating Directly over TCP | RMCLink Component | Delta Motion Control Protocol
Copyright © 2024 Delta Computer Systems, Inc. dba Delta Motion