Phoenix DX Series User manual

PHOENIX AC DRIVE
DX, EX, DS & ES
3 TO 3500 HP
MODBUS RTU PROTOCOL
MODBUS TCP PROTOCOL
MODBUS USD PROTOCOL
MODBUS PROTOCOL

TABLE OF CONTENTS i
SECTION TITLE PAGE
1.0 INTRODUCTION 1-1
2.0 HARDWARE INTERFACE 2-1
2.1 RS-485 4 Wire Operation 2-1
2.2 RS-422 4 Wire Operation 2-1
2.3 RS-232 Operation 2-1
2.3.1 RS-232C-to-RS-422 Interface 2-1
Adapter
2.3.2 Direct RS-232 Wiring 2-1
2.3.3 RS-232 Isolated Communications
Interface 2-2
2.4 Ethernet Operation 2-2
3.0 MODBUS RTU PROTOCOL 3-1
DESCRIPTION
3.1 Introduction Modbus Protocol 3-1
3.1.1 Transaction on Modbus Networks 3-1
3.1.2 The Query-Response Cycle 3-1
3.2 Two Serial Transmission Modes 3-1
3.2.1 RTU Mode 3-2
3.2.2 ASCII Mode 3-2
3.3 Modbus Message Framing 3-2
3.3.1 RTU Framing 3-2
3.3.2 ASCII Framing 3-3
3.3.3 How the Address Field is Handled 3-3
3.3.4 How the Function Field is Handled 3-3
3.3.5 Contents of the Data Field 3-3
3.3.6 Contents of the Error Checking Field 3-4
3.3.7 How Characters are Transmitted 3-4
Serially
3.4 Error Checking Methods 3-4
3.4.1 Parity Checking 3-4
3.4.2 CRC Checking 3-5
4.0 MODBUS TCP PROTOCOL
DESCRIPTIONS 4-1
4.1 Ethernet Frame 4-1
4.2 Modbus TCP Message Framing 4-1
4.3 Modbus TCP Header Description 4-1
4.4 Ethernet TCP Message Framing 4-2
5.0 MODBUS FUNCTION FORMATS 5-1
5.1 Field Contents in Modbus Messages 5-1
5.2 Function Codes 5-1
6.0 PHOENIX AC DRIVE FUNCTION 6-1
FORMATS
6.1 MODBUS USD Function Formats 6-1
6.2 MODBUS RTU Function Formats 6-3
6.3 MODBUS USD Alternate Function Format 6-4
SECTION TITLE PAGE
7.0 EXCEPTION RESPONSE 7-1
7.1 Exception Codes 7-1
8.0 CRC GENERATION 8-1
9.0 PARAMETER CONVERSION 9-1
9.1 Parameter Coding Format 9-1
9.2 Parameter to Register Address
Conversion 9-1
APPENDIX PAGE
1.0 INTRODUCTION A-1
1.1 Introduction A-1
1.2 Layering A-1
2.0 NETWORK LAYER A-2
2.1 IP A-2
2.2 IP Address A-2
2.3 IP Address Classes A-3
2.4 Netmasks A-3
2.5 Subnet Address A-3
2.6 Directed Broadcast Address A-3
2.7 Limited Broadcast Address A-3
2.8 ICMP A-3
3.0 LINK LAYER A-3
3.1 ARP A-3
4.0 THE TRANSPORT LAYER A-4
4.1 UDP A-4
4.2 TCP A-4
5.0 THE APPLICATION LAYER A-4
5.1 DNS A-4
6.0 ETHERNET FRAME A-4
6.1 Ethernet Frame A-4
6.2 Encapsulation A-4

LIST OF FIGURES AND TABLES
ii
FIGURE TITLE PAGE
2.1 RS-485 4-Wire Multi Drop Hookup 2-3
2.2 RS-422 4-Wire Point-to-Point Hookup 2-3
2.3 Quasi – RS 232 Hookup 2-3
2.4 Installation of Isolated RS-422/485 Board 2-4
2.5 Installation of Removable RS-232 Isolated
Communication Interface with Cable 2-5
2.6 Installation of Isolated RS-422/485 Board 2-6
2.7 Installation of Removable USB-RS-485
Isolated Communications Interface 2-7
4.1 Ethernet Frame 4-1
4.2 Encapsulation of Modbus RTU Frame 4-1
4.3 Encapsulation of Modbus RTU Frame
In Ethernet Frame 4-2
APPENDIX
FIGURES TITLE PAGE
A-1 The Four Layers of the TCP/IP Protocol
Suite A-1
A-2 Two Hosts on a LAN Running TCP A-2
A-3 Various Protocols at Different Layers
In the TCP/IP Protocol Suite A-2
A-4 Ethernet Frame (RFC 894) A-4
A-5 Encapsulation of Data as it goes down
The Protocol Stack Page A-5

INTRODUCTION 1-1
1.0 INTRODUCTION
The US DRIVES PHOENIX digital AC drive has an
optional isolated serial communication interface that
enables the user to control and setup the drive using a
host computer, such as an IBM compatible PC. The
drive’s serial interface may be configured to support
either the RS-422 or RS-485 interconnect standard. In
addition, schematics shown in this document show a
simple hookup that permits an RS-232 interface (this
hookup does not meet EIA standards, due to noise
immunity levels, but will work with most host
computers). The PHOENIX Modbus USD protocol is
loosely based on the MODBUS RTU Protocol and
features full CRC (Cyclical Redundancy Check)
protection in both directions. The Phoenix drive
defaults to 9600 Baud Rate, No Parity, 8-Bit Data and
2 Stop Bits.
Using an RS-485 serial interconnect, up to 32 drives
can be party-lined to permit the host computer to
setup and query any one of them. With using the
Ethernet Communications Card, any host computer on
a network can communicate to the Phoenix AC Drives.
The PHOENIX AC drive contains an onboard database
of over 282 parameters that define and describe drive
setups and operating conditions. In essence, a user
armed with a printout of the drive’s parameters can
configure and operate the drive with a simple read
and write command to the desired parameter.
For those users wishing to develop their own host
computer drive control software, the following sections
of this manual describe the Modbus USD, Modbus
RTU, and Modbus TCP Protocols that are used.

1-2 INTRODUCTION
END OF INTRODUCTION SECTION

HARDWARE INTERFACE 2-1
2.0 HARDWARE INTERFACE
2.1 RS-485 4-Wire Operation
RS-485 and RS-422 interfaces use differential
transceivers for increased noise immunity, since any
noise induced in one wire will usually be induced in
the other wire and thus will be canceled out at the
differential receiver.
RS-485 4-Wire operation allows 32 drivers and 32
receivers to be party-lined together at distances up to
4000 feet. This allows a host computer to talk to 31
drives. The host computer has its transmitter and
receiver enabled at all times. The drives always have
their receivers enabled but only one drive transmitter
on the party-line can be enabled at any one time.
The host computer transmits a query to a specific
drive (queries have an address field that identifies the
destination drive). Even though all drives on the
party-line or network receive the query and decode it,
only one drive will prepare and transmit a response.
The destination drive enables its transmitter during its
response and disables it immediately after
transmission is complete. This sequencing of the drive
transmitters is built into the PHOENIX drive software.
The host software requires no special hand-shaking
since the transmitter and receiver are enabled at all
times.
There are a number of electrical supply houses that
offer RS-485 interface cards for IBM-compatible PCs.
US Drives has decided to only support 4-Wire RS-485
and RS-422 operation because standard MS-DOS serial
device drivers may be used without modification. The
proper hookup for 4-Wire RS-485 Multi-Drop between
a host PC and a number of PHOENIX drives is shown
in Figure 2-1.
2.2 RS-422 4-Wire Operation
RS-422 4-Wire operation is similar to RS-485 4-Wire
operation except that the wiring is “point-to-point”
with no other drives party-lined. This mode works at
full duplex and is illustrated in Figure 2-2.
2.3 RS-232 Operation
The PHOENIX drive permits a direct RS-232 interface.
It is felt, however, that the differential transmission
scheme offered by the RS-422/485 standard is much
more suitable for an industrial environment. Direct
connection to a PC using the RS-232 scheme is not
recommended for drives operating on the factory
floor.
Those users that still wish to use a RS-232 interface
have the following alternatives.
2.3.1 RS-232C-to-RS-422 Interface
Adapter
Users who wish to use the PC’s RS-232C serial port
can install a RS-232C-to-RS-422 converter that is
readily available from a number of electrical suppliers.
It need not be isolated, as the PHOENIX user serial
port is already electrically isolated from the rest of the
drive. These converters typically look much like a “25
pin gender changer” plug with the conversion circuits
built into the plug. Power is normally supplied to the
converter by an AC-DC adapter that plugs into an
110vac duplex outlet.
2.3.2 Direct RS-232 Wiring
The following “scheme” is not recommended for
permanent use. By connecting the +RXD and +TXD
pins to the PC RS-232 ground, a quasi-single ended
RS-232 interface can be accomplished.
Normal RS-232C signals bounce between +10 volts
and –10 volts (the positive rail voltage can be between
the values of +3 volts and +25 volts – likewise for the
negative rail). Thus, +10 volts is interpreted as a logic
“0” while -10 volts is interpreted as a logic “1”. Most
RS-232C receivers will detect zero volts as a logic “1”
due to hysteresis effects which allows the wiring
scheme shown in Figure 2-3 to work (usually!).
This direct connection generates RS-232C levels of
approximately +3.7 volts to -3.7 volts. Note that the
isolated RS-422/485 common on the PHOENIX control
board (TB6-5) must not be grounded or it will short-
circuit the +TXD line if the PC is grounded. This direct
RS-232 wiring scheme, if it must be done, is most
appropriate when using a laptop PC that is floating
from earth ground.

2-2 HARDWARE INTERFACE
2.3.3 RS-232 Isolated Communication
Interface
Using the Removable RS-232 Isolated Communication
Interface, user’s can use the PC’s RS-232C serial port.
The Communication Interface isolates the PC from the
Phoenix AC Drive and no external power supply is
needed. This comes with D9 female connector, 10’
cable, and removable RS-232 Isolated Communication
interface. Figure 2.6 shows the installation of the
removable RS-232 Isolated Communication card.
2.4 Ethernet Operation
Ethernet is a local area network technology that
transmits information between devices at speeds of 10
and 100 mbps. The word Ethernet refers to hardware
called out in IEEE specification 802.3 and has become
an increasingly popular medium for communication in
industrial environments. The protocols are
implementation of TCP and UDP transport used with
Ethernet hardware. This allows many different
applications to run over the same network and the
same cables. Thus, webservers and email run on the
same physical connection courtesy of TCP/IP.
The Ethernet Gateway Device is used to interface
Phoenix AC Drives to Ethernet Network. The figure
below shows a typical network connection of the
Phoenix AC Drives using a Ethernet Gateway Device.
INTERNET/INTRANET
PLC
PC
ETHERNET
GATEW AY
DEVICE
ETHERNET PATCH
CABLE
NETWORK HUB
OR
SW ITCH
PHOENIX
AC
DRIVE
#1
PHOENIX
AC
DRIVE
#2
PHOENIX
AC
DRIVE
#2
SERIAL RS
-
485 4 WIRE

HARDWARE INTERFACE 2-3
Figure
2.3
Figure 2.2
Figure 2.1

2-4 HARDWARE INTERFACE
Isolated Communication Card 3000-4135-1
Installation of Isolated RS-422/485 Board
(with Control Board 3000-4100 & 3000-4130)
Figure 2.4

HARDWARE INTERFACE 2-5
Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB
Installation of Removable USB-RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB (with Control Board 3000-4100 & 3000-4130)
Figure 2.5

2-6 HARDWARE INTERFACE
Isolated Communication Card 3000-4135
Installation of Isolated RS-422/485 Board
(with Control Board 3000-4101 & 3000-4131)
Figure 2.6

HARDWARE INTERFACE 2-7
Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB
Installation of Removable USB/RS-485 Isolated Communications Interface with Cable
P/N: 3000-4226-USB (with Control Board 3000-4101 & 3000-4131)
Figure 2.7

2-8 HARDWARE INTERFACE
END OF HARDWARE INTERFACE

MODBUS RTV PROTOCAL DESCRIPTION 3-1
3.0 MODBUS RTU PROTOCOL
DESCRIPTION
3.1 Introduction Modbus Protocol
The common language used by Phoenix AC Drives is
the Modbus protocol. This protocol defines a message
structure that Phoenix AC Drives will recognize and
use.
The Modbus protocol provides the internal standard
that the Phoenix AC Drives use for parsing messages.
During communications on a Modbus network, the
protocol determines how each drive will know its
device address, recognize a message addressed to it,
determine the kind of action to be taken, and extract
any data or other information contained in the
message. If a reply is required, the drive will
construct the reply message and send it using Modbus
protocol.
3.1.1 Transaction on Modbus Networks
Controllers communicate using a master-slave
technique, in which only one device (the master) can
initiate transactions (queries). The other devices (the
slaves) respond by supplying the requested data to
the master, or by taking the action requested in the
query. Typical master devices include host
processors. Typical slaves include Phoenix AC Drives.
The master can address individual slaves, or can
initiate a broadcast message to all slaves. Slaves
return a message (response) to queries that are
addressed to them individually. Responses are not
returned to broadcast queries from the master.
The Modbus protocol establishes the format for the
master’s query by placing into it the device (or
broadcast) address, a function code defining the
requested action, any data to be sent, and an error-
checking field. The slave’s response message is also
constructed using Modbus protocol. It contains fields
confirming the action taken, any data to be returned,
and an error-checking field. If an error occurred in
receipt of the message, or if the slave is unable to
perform the requested action, the slave will construct
an error message and send it as its response.
3.1.2 The Query-Response Cycle
Master-Slave Query-Response Cycle
The Query
The function code in the query tells the addressed
slave device what kind of action to perform. The data
bytes contain any additional information that the slave
will need to perform the function. For example,
function code 03 will query the slave to read holding
registers and respond with their contents. The data
field must contain the information telling the slave
which register to start at and how many registers to
read. The error check field provides a method for the
slave to validate the integrity of the message contents.
The Response
If the slave makes a normal response, the function
code in the response is an echo of the function code in
the query. The data bytes contain the data collected
by the slave, such as register values or status. If an
error occurs, the function code is modified to indicate
that the response is an error response, and the data
bytes contain a code that describes the error. The
error check field allows the master to confirm that the
message contents are valid.
3.2 Two Serial Transmission Modes
Devices communicate on standard Modbus networks
using either of two transmission modes: ASCII or RTU.
Phoenix AC drives use RTU mode, but select the serial
port communication parameters (baud rate, parity
mode, etc.), during configuration of each drive. The
mode and serial parameters must be the same for all
devices on a Modbus network.
Device Address
Function Code
Eight-Bit
Data Bytes
Error Check
Device Address
Function Code
Eight-Bit
Data Bytes
Error Check
Query messa
g
e from master
Response messa
g
e from slave

3-2 MODBUS RTV PROTOCAL DESCRIPTION
3.2.1 RTU Mode
The Phoenix AC drive are setup to communicate on a
Modbus network using RTU (Remote Terminal Unit)
mode, each eight-bit byte in a message contains two
four-bit hexadecimal characters. The main advantage
of this mode is that its greater character density allows
better data throughput than ASCII for the same baud
rate. Each message must be transmitted in a
continuous stream.
Coding System
Eight-bit binary, hexadecimal 0…9, A…F
Two hexadecimal characters contained in each eight-
bit field of the message.
Bits per Byte
1 start bit
8 data bits, least significant bit sent first
1 bit for even/odd parity-no bit for no parity
1 stop bit if parity is used-2 bits if no parity
Error Check Field
Cyclical Redundancy Check (CRC)
3.2.2 ASCII Mode
The Phoenix AC drive does not incorporate ASCII
(American Standard Code for Information
Interchange) mode. But, if a device is using ASCII
mode, each eight-bit byte in a message is sent as two
ASCII characters. The main advantage of this mode is
that it allows time intervals of up to one second to
occur between characters without causing an error.
Coding System
Hexadecimal, ASCII characters 0… 9, A…F
One hexadecimal character contained in each ASCII
character of the message.
Bits per Byte
1 start bit
7 data bits, least significant bit sent first
1 bit for even/odd parity-no bit for no parity
1 stop bit if parity is used-2 bits if no parity
Error Check Field
Longitudinal Redundancy Check (LRC)
3.3 Modbus Message Framing
In either of the two serial transmission modes (ASCII
or RTU), a Modbus message is placed by the
transmitting device into a frame that has a known
beginning and ending point. This allows receiving
devices to begin at the start of the message, read the
address portion and determine which device is
addressed (or all devices, if the message is broadcast),
and to know when the message is completed. Partial
messages can be detected and errors can be set as a
result.
3.3.1 RTU Framing
In RTU mode, messages start with a silent interval of
at least 3.5 character times. This is most easily
implemented as a multiple of character times at the
baud rate that is being used on the network (shown as
T1 – T2 – T3 – T4 in the figure below). The first field
then transmitted is the device address.
The allowable characters transmitted for all fields are
hexadecimal 0…9, A…F. Networked devices
monitor the network bus continuously, including
during the silent intervals. When the first field (the
address field) is received, each device decodes it to
find out if it is the addressed device.
Following the last transmitted character, a similar
interval of at least 3.5 character times marks the end
of the message. A new message can begin after this
interval.
The entire message frame must be transmitted as a
continuous stream. If a silent interval of more than
1.5 character times occurs before completion of the
frame, the receiving device flushes the incomplete
message and assumes that the next byte will be the
address field of a new message.
Similarly, if a new message begins earlier that 3.5
character times following a previous message, the
receiving device will consider it a continuation of the
previous message. This will set an error, as the value
in the final CRC field will not be valid for the combined
messages. A typical message frame is shown below.
START ADDRESS FUNCTION DATA CRC
CHECK END
T1-T2-T3-T4 8 BITS 8 BITS NX8BITS 16 BITS T1-T2-T3-T4

MODBUS RTV PROTOCAL DESCRIPTION 3-3
3.3.2 ASCII Framing
In ASCII mode, which is not incorporated in Phoenix
AC drives, messages start with a colon (: character
(ASCII 3A hex), and end with a carriage return-line
feed (CRLF) pair (ASCII 0D and 0A hex).
The allowable characters transmitted for all other
fields are hexadecimal 0… 9, A… F. Networked
devices monitor the network bus continuously for the
colon character. When one is received, each device
decodes the next field (the address field) to find out if
it is the addressed device.
Intervals of up to one second can elapse between
characters within the message. If a greater interval
occurs, the receiving device assumes an error has
occurred. A typical message frame is shown below.
START SLAVE
ADDRESS FUNCTION DATA LRC CHECK END
1
CHAR
:
2
CHARS 2 CHARS N CHARS 2 CHARS
2
CHARS
CRLF
3.3.3 How the Address Field is Handled
The address field of a message frame contains eight
bits (RTU). Valid slave device addresses are in the
range of 0…247 decimal. The individual slave devices
are assigned addresses in the range of 1…247. A
master addresses a slave by placing the slave address
in the address field of the message. When the slave
sends its response, it places its own address in this
address field of the response to let the master know
which slave is responding.
Address 0 is used for the broadcast address, which all
slave devices recognize. When Modbus protocol is
used on higher level networks, broadcasts may not be
allowed or may be replaced by other methods. For
example, Modbus Plus uses a shared global database
that can be updated with each token rotation.
3.3.4 How the Function Field is
Handled
The function code field of a message frame contains
eight bits (RTU). Valid codes are in the range of
1…255 decimal. Of these, some codes are applicable
to all Modicon controllers, while some codes apply only
to certain models, and others are reserved for future
use.
When a message is sent from a master to a slave
device the function code field tells the slave what kind
of action to perform. Examples are to read the
ON/OFF states of a group of discrete coils or inputs; to
read the data contents of a group of registers; to read
the diagnostic status of the slave; to write to
designated coils or registers; or to allow loading,
recording, or verifying the program within the slave.
When the slave responds to the master, it uses the
function code field to indicate either a normal (error-
free) response or that some kind of error occurred
(called an exception response). For a normal
response, the slave simply echoes the original function
code. For an exception response, the slave returns a
code that is equivalent to the original function code
with its most significant bit set to a logic 1.
For example, a message from master to slave to read
a group of holding registers would have the following
function code.
0000 0011 (Hexadecimal 03)
If the slave device takes the requested action without
error, it returns the same code in its response. If an
exception occurs, it returns:
1000 0011 (Hexadecimal 83)
In addition to its modification of the function code for
an exception response, the slave places a unique code
into the data field of the response message. This tells
the master what kind of error occurred, or the reason
for the exception.
The master device’s application program has the
responsibility of handling exception responses. Typical
processes are to post subsequent retries of the
message, to try diagnostic messages to the slave, and
to notify operators.
3.3.5 Contents of the Data Field
The data field is constructed using sets of two
hexadecimal digits, in the range of 00 to FF
hexadecimal. These can be made from one RTU
character.
The data field of messages sent from a master to
slave devices contains additional information, which
the slave must use to take the action defined by the
function code. This can include items like discrete and
register addresses, the quantity of items to be
handled, and the count of actual data bytes in the
field.
For example, if the master requests a slave to read a
group of holding registers (function code 03), the data
field specifies the starting register and how many

3-4 MODBUS RTV PROTOCAL DESCRIPTION
registers are to be read. If the master writes to a
group of registers in the slave (function code 10
hexadecimal), the data field specifies the starting
register, how many registers to write, the count of
data bytes to follow in the data field, and the data to
be written into the registers.
If no error occurs, the data field of a response from a
slave to a master contains the data requested. If an
error occurs, the field contains and exception code
that the master application can use to determine the
next action to be taken.
The data field can be nonexistent (of zero length) in
certain kinds of messages. For example, in a request
from a master device for a slave to respond with its
communications event log (function code 0B
hexadecimal), the slave does not require any
additional information. The function code alone
specifies the action.
3.3.6 Contents of the Error Checking
Field
RTU Mode
When RTU mode is used for character framing, the
error checking field contains a 16-bit value
implemented as two eight-bit bytes. The error check
value is the result of a Cyclical Redundancy Check
calculation performed on the message contents.
The CRC field is appended to message as the last field
in the message. When this is done, the low-order
byte of the field is appended first, followed by the
high-order byte. The CRC high-order byte is the last
byte to be sent in the message.
3.3.7 How Characters are Transmitted
Serially
With RTU character framing, the bit sequence is:
With Parity Checking
Start 1 2 3 4 5 6 7 8 Par Stop
Start 1 2 3 4 5 6 7 8 Stop Stop
Bit Order (RTU)
3.4 Error Checking Methods
Standard Modbus serial networks use two kinds of
error checking. Parity checking (even or odd) can be
optionally applied to each character. Frame checking
(LRC or CRC) is applied to the entire message. Both
the character check and message frame check are
generated in the master device and applied to the
message content before transmission. The slave
checks each character and the entire message frame
during receipt.
The master is configured by the used to wait for a
predetermined timeout interval before aborting the
transaction. This interval is set to be long enough for
any slave to respond normally. If the slave detects a
transmission error, the message will not be acted
upon. The slave will not construct a response to the
master. Thus the timeout will expire and allow the
master’s program to handle the error.
3.4.1 Parity Checking
Users can configure Phoenix AC drives for Even or Odd
Parity checking, or for No Parity checking. This will
determine how the parity bit will be set in each
character.
If either Even or Odd Parity is specified, the quantity
of 1 bit will be counted in the data portion of each
character (eight for RTU). The parity bit will then be
set to a 0 or 1 to result in an Even or Odd total of 1
bits. For example, these eight data bits are contained
in an RTU character frame:
1100 0101
The total quantity of 1 bits in the frame is four. If
Even Parity is used, the frame’s parity bit will be a 0,
making the total quantity of 1 bits still an even
number (four). If Odd Parity is used, the parity bit will
be a 1, making an odd quantity (five).
When the message is transmitted, the parity bit is
calculated and applied to the frame of each character.
The receiving device counts the quantity of 1 bits and
sets an error if they are not the same as configured
for that device (all devices on the Modbus network
must be configured to use the same parity check
method).
Note that Parity Checking can only detect an error if
an odd number of bits are picked up or dropped in a
character frame during transmission. For example, if
Odd Parity checking is employed, and two 1 bits are
dropped form a character containing three 1 bits, the
result is still an odd count of 1 bits.
Without Parity Checking

MODBUS RTV PROTOCAL DESCRIPTION 3-5
If No Parity checking is specified, no parity bit is
transmitted and no parity check can be made. An
additional stop bit is transmitted to fill out the
character frame.
3.4.2 CRC Checking
In RTU mode, messages include an error-check field
that is based on a CRC method. The CRC field checks
the contents of the entire message. It is applied
regardless of any parity check method used for the
individual characters of the message.
The CRC field is two bytes, containing a 16-bit binary
value. The CRC value is calculated by the transmitting
device, which appends the CRC to the message. The
receiving device recalculates a CRC during receipt of
the message, and compares the calculated value to
the actual value it received in the CRC field. If the two
values are not equal, an error results.
The CRC is started by first preloading a 16-bit register
to all 1’s. Then a process begins of applying
successive eight-bits bytes of the message to the
current contents of the register. Only the eight bits of
data in each character are used for generating the
CRC. Start and stop bits, and the parity bit, do not
apply to the CRC.
During generation of the CRC, each eight-bit character
is exclusive ORed with the register contents. Then the
result is shifted in the direction of the least significant
bit (LSB), with a zero filled into the most significant bit
(MSB) position. The LSB is extracted and examined.
If the LSB was a 1, the register is then exclusive ORed
with a preset, fixed value. If the LSB was a 0, no
exclusive OR takes place.
This process is repeated until eight shifts have been
performed. After the last (eighth) shift, the next
eight-bit byte is exclusive ORed with the register’s
current value, and the process repeats for eight more
shifts as described above. The final contents of the
register, after all the bytes of the message have been
applied, is the CRC value.
When the CRC is appended to the message, the low-
order byte is appended first, followed by the high-
order byte.

3-6 MODBUS RTV PROTOCAL DESCRIPTION
END OF MODBUS RTU PROTOCAL DESCRIPTION

MODBUS TCP PROTOCOL DESCRIPTION 4-1
4.0 MODBUS TCP PROTOCAL
DESCRIPTION
This section describes the general form of
encapsulation of Modbus request and response when
carried on the Ethernet network. It is important to
note that the structure of the request and response
body, from the slave address to the end of the data
portion, have exactly the same way out and meaning
as in the other Modbus variants.
4.1 Ethernet Frame
Figure 4.1 Ethernet Frame
The above figure shows an Ethernet frame. The
message framing is encapsulated into the application
data of the Ethernet frame.
4.2 Modbus TCP Message Framing
TRANSACTION
IDENTIFIER
PROTOCOL
IDENTIFIER
LENGTH
FIELD
SLAVE ADDRESS
UNIT
IDENTIFIER
FUNCTION DATA
2x8 BITS
16 BITS
2x8 BITS
16 BIT
S
2x8 BITS
16 BITS 8 BITS
8 BITS NX8BITS
Figure 4.2 Encapsulation of Modbus RTU Frame in
Ethernet Frame as Modbus TCP
The Modbus RTU frame request and responses as
Modbus TCP message framing is inserted into
application data location. The Modbus RTU message
frame start, stop, and cRC are not included into the
Modbus TCP frame. A Modbus TCP header is added
and the slave address is replaced by a unit identifier.
The unit identifier is considered part of the header.
4.3 Modbus TCP Header Description
The Modbus TCP Header contains the following
fields:
Fields Length Description Client Server Contents
Byte 0
Usually
0Transaction
Identifier 2 Bytes Identification of a MODBUS
Request / Response
transaction
Initialized by
the client
Recopied by the
server from the
received request
Byte 1
Usually
0
Byte 2 0
Protocol
Identifier 2 Bytes 0 = MODBUS protocol Initialized by
the client
Recopied by the
server from the
received request
Byte 3 0
Byte 4 0
Length 2 Bytes Number of following bytes Initialized by
the client
(request)
Initialized by the
server
(Response)
Byte 5
Number
of Bytes
Unit
Identifier 1 Byte Identification of a remote
slave connected on a serial
line or on other buses
Initialized by
the client
Recopied by the
server from the
received request
The header is 6 bytes long:
•Transaction Identifier – It is used for
transaction pairing, the Modbus server copies in
the response the transaction identifier of the
request.
•Protocol Identifier – It is used for intra-system
multiplexing. The Modbus protocol is identified
by the value 0.
•Length – The length field is a byte count of the
Unit Identifier, Function Code, and Data Fields.
•Unit Identifier – This field is used for intra-
system routing purpose. It is typically used to
communicate to a Modbus serial line slave
through a gateway between an Ethernet TCP/IP
network and a Modbus serial line. This field is
set by the Modbus Client in the request and must
be returned with the same value in the response
by the server.
All Modbus/TCP Message Frames are sent via TCP on
registered port 502.
Etherne
t
header IP header TCP header application data Etherne
t
trailer
20 2014 4
Ethernet Frame
46 to 1500 b
y
tes
MODBUS TCP HEADER MODBUS RTU FRAME
Etherne
t
header IP
header TCP
header application data Etherne
t
trailer
Ethernet Frame
14 20 20 4
46 to 1500 b
y
tes