Master Ethernet controllers can communicate with the RMC using several methods. This topic describes only one of those methods—using raw TCP 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 TCP data on that platform. Some PLCs provide access to TCP connections 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 TCP-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 TCP 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.
The DMCP protocol requires using raw TCP packets, which is not the default in some programming languages.
NOTE: Avoid repeatedly closing and re-opening TCP connections. Devices are required to maintain state on TCP connections for two minutes after the connections are closed, and repeatedly opening and closing TCP connections can exhaust resources in the RMC or host device. Instead the connection should be left open by the host device while communicating with the RMC. If your host device is not able to keep the connection open indefinitely, then consider using UDP instead, as described in Communicating Directly over UDP.
Delta has an example C code implementation of DMCP on its forum: https://forum.deltamotion.com/
For RMC75E and RMC150E firmware versions prior to 3.31.0, Delta recommended using the Mitsubishi Procedure Exist protocol for direct communication over TCP. For details, see the Mitsubishi Procedure Exist topic.
Tip: An example implementation of DMCP in the C programming language is available in the Examples section of Delta's online forum.
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. |
|
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 1024. 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 can 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. |
|
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 1024. 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 can 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 an error response, but will instead either discard the incoming packet with no response, or close the TCP/IP connection:
The Packet Length field is less than 5. The RMC will discard the packet without response.
The Packet Length field is greater than 4110. The connection will be closed.
Unable to receive the entire packet from the TCP stream. The connection will be closed.
Unable to successfully send the response over the TCP stream. The connection will be closed.
The Static Values (bytes 2-3) are not 00 and 02 respectively. The RMC will discard the packet without response.
Unsupported function code (byte 6). The RMC will discard the packet without response.
The errors above are also logged in the Event Log.
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 TCP 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 TCP 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 UDP | RMCLink Component | Delta Motion Control Protocol
Copyright © 2024 Delta Computer Systems, Inc. dba Delta Motion