Delta Motion Control Protocol (DMCP)
User Guide
Why Another Protocol?
The RMC supports many application protocols; most were designed by other automation
companies. However, when Delta Computer Systems, Inc. needed to choose a protocol
to use for its own software, such as the RMCENET ActiveX Control, to communicate
with the RMC, it found that none of these protocols satisfied this simple list of
requirements:
1. It must have binary, little-Endian, word-aligned encoding.
2. It must have low data and processing overhead.
3. It must be flexible enough to allow addressing of a minimum of 65,536 16-bit
registers.
4. It must be non-connection based to support both UDP and TCP operating modes.
Therefore, Delta designed yet another application protocol, called Delta Motion Control
Protocol (DMCP).
DMCP versus Modbus/TCP
Users who want to control or monitor the RMC through TCP or UDP must select one of
the protocols the RMC supports. Delta recommends two of these protocols: DMCP and
Modbus/TCP. All other protocols supported by the RMC are either difficult to get
information on, complicated, or inefficient. We will now compare DMCP and
Modbus/TCP.
DMCP was designed by Delta Computer Systems for its own products and is not
implemented by other manufacturers. Modbus/TCP is an open protocol maintained by
Schneider Electric and implemented by many manufacturers; this is the main advantage
of Modbus/TCP.
The following chart compares the technical specifications of these two protocols:
Characteristics DMCP Modbus/TCP
Transport Protocols
Byte Order
Data Alignment
Static Header Size
Maximum 16-bit
Registers per Packet
TCP, UDP TCP
Big or Little Endian Big Endian (Motorola)
16-bit 8-bit
7 bytes 8 bytes
TCP: 2048
UDP: 512
Read: 125
Write: 100
DMCP User Guide Page 1 of 9 October 23, 2001
Because of the above statistics, DMCP can be significantly faster than Modbus/TCP, as
demonstrated by the following benchmark data:
Benchmarks DMCP Modbus/TCP
Read 125 words
TCP: 6.27 ms
6.46 ms
UDP: 5.21 ms
Read 512 words
TCP: 12.0 ms
31.2 ms (5 packets)
UDP: 10.4 ms
Read 2048 words
TCP: 35.9 ms
109 ms (17 packets)
UDP: 42.4 ms (4 packets)
Although DMCP is up to three times faster for large packets, it is worth noting that the
majority of transfers for most applications are to the status and command areas, which are
both under 125 words. On those transfers the speed advantage is smallest. These
statistics were taken from a Windows application requesting data from an RMC.
From the above information, the selection criteria can be simplified to the following:
• Choose Modbus/TCP if you want to be able to reuse your code with non-Delta
Ethernet products in the future.
• Choose DMCP if you need the additional performance, especially sending large
amounts of data.
The rest of this document is dedicated to defining DMCP. For more information on
Modbus/TCP, see Schneider Electric’s web site at www.modicon.com.
DMCP Characteristics
DMCP satisfies the above requirements, which restated and slightly appended, comes to
this basic list of characteristics:
• DMCP servers will listen on registered TCP and/or UDP ports 1324. The RMC
listens on both. It also listens on TCP and UDP private ports 50000 because this was
the port used before we had a registered port. This private port is being phased out.
NOTE: Prior to RMC ENET firmware 20001108, the RMC only listened on the
private ports. However, these ports are being phased out, so we
recommend updating to 20001108 or newer firmware rather than using the
private ports.
• All values are binary encoded. Values larger than a byte will be word-aligned and be
in little-Endian (LSB first) format. The exception to this is that the data contents of
reads and writes can be issued in either big- or little-Endian, depending on the
function used.
• No checksum is included in this application layer protocol since it this data is already
checked in the TCP, UDP (optionally), and Ethernet protocols.
• No source and destination node addresses will be added to the protocol, as the source
and destination IP addresses and port numbers are already available in the IP, TCP,
and UDP layers.
DMCP User Guide Page 2 of 9 October 23, 2001
DMCP Format
DMCP is a simple request/response protocol. Once the client has an open TCP or UDP
connection, the client sends a request packet and the server responds with a packet. Of
course, UDP has no communication connection, but some API’s, including BSD sockets,
allow opening a virtual connection to avoid entering the IP address in every function call.
The client may send several requests—the server must respond in the order received—but
it is intended that only a few requests are made at a time, so the server can be designed
accordingly.
DMCP request packets have this simple format:
PktLen 00
Ver SeqNum FC
FC-specific data
DMCP response packets have the exact same format as the request except that function
codes will have response bits set (see below) and the FC-specific data will be different.
NOTE: Prior to RMC ENET firmware 20000420, the RMC used version 1 of the packet
format, which is not documented here. We recommend instead upgrading to
20001108 or newer firmware.
The above fields are each described below:
• PktLen
This field gives the number of bytes in the entire packet excluding only the 2-byte
PktLen field. The valid range for this field is 5 to 1034 when using UDP and 5 to
4106 when using TCP.
• Ver
This gives the packet format version. Currently, this should be 02.
• SeqNum
The sequence number is echoed in the response from a server. The client need not
use this field, but when the UDP transport is used, it is highly recommended that the
sequence number be used to ensure that the responses received match the requests,
since packets can arrive out of order.
• FC (Function Code)
This single-byte field identifies the operation that will be made. The rest of this
document describes function codes and their usage. Function codes will always be
displayed in hexadecimal to simplify this document. Valid function code requests
will always fall between 00 and 1F. Response function codes will be fall into two
categories. Success response function codes are equal to the request function code
plus 80 (i.e. the range is 80 to 9F). Failure response function codes are equal to the
request function code plus 40 (i.e. the range is 40 to 5F).
• FC-specific data
Many function codes require additional data in the request and/or response packets.
DMCP User Guide Page 3 of 9 October 23, 2001
Loading...