ABB Modbus AN00198 Reference manual

ABB Motion control products 1
new.abb.com/motion
Modbus is an industry standard protocol that allows a
variety of automation devices (such as Programmable
Logic Controllers and Human Machine Interfaces) to
communicate with each other. The Modbus protocol
defines a simple protocol data unit (PDU) that is
independent of the underlying communication layers.
Inclusion of Modbus protocol support as standard
makes integration of ABB products with any other
Modbus RTU/TCP device as simple as possible.
Introduction
Controllers communicate (via RS232/422/485 Serial or Ethernet) using a Client / Server topology, in which only one device (the
Client) can initiate transactions (called ‘queries’). The other devices (the Servers) respond by supplying the requested data to
the Client, or by taking the action requested in the query. Typical Client devices include host processors and programming
panels. Typical Servers include programmable controllers.
The Client can address individual Servers, or can initiate a broadcast message to all Servers. Servers return a message (called
a ‘response’) to queries that are addressed to them individually. Responses are not returned to broadcast queries from the
Client.
The Modbus protocol establishes the format for the Client’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 Server’s response message is also
constructed using the 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 Server is unable to perform the requested action, the
Server will construct an error message and send it as its response.
Motion Control Products
Application note
Integrated Modbus support
AN00198
Rev E (EN)

Application note Integrated Modbus support AN00198
ABB Motion control products 2
new.abb.com/motion
Methods of Modbus communications configuration
There are two different methods (depending on the motion product used) of configuring communication in the controller/drive via
Modbus. Older motion controllers and drives or those with older firmware use a program based Mint interpreter and the newer
products have the Modbus functions integrated into the firmware.
Please refer to the table below to select the appropriate firmware for integrated Modbus usage:
Product with integrated Modbus support
RTU
TCP
Required firmware
NextMove ESB-2
Yes
-
5424 onwards
NextMove e100
Yes
Yes
5633 onwards
MicroFlex e100
Yes
Yes
5633 onwards
MicroFlex e150
Yes
Yes
All versions
MicroFlex e190
No
Yes
All versions
MicroFlex e190 equipped with OPT-SIO-1 option card
Yes
Yes
5900 onwards
MotiFlex e100
Yes
Yes
5633 onwards
MotiFlex e180
No
Yes
All versions
The Integrated Modbus functionality is described in more detail below.
For more specific information on how to use and set up the Mint based Modbus refer to the corresponding Application Note
AN00185 - Mint based Modbus RTU Server
Getting Started with Modbus
Data format
When controllers are setup to communicate on a Modbus network using RTU (Remote Terminal Unit) mode, each 8–bit byte in
a message contains two 4–bit hexadecimal characters. Each message must be transmitted in a continuous stream.
The Mint interpreter offers support for Client devices with communication settings of:
•7 data bits, 1 stop bit, Even Parity
•7 data bits, 1 stop bit, Odd Parity
•8 data bits, 1 stop bit, No Parity
Baud rates are limited to those supported by the Mint controller (and of course must match the baud rate setting made on the
Modbus Client device).
Message 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.
The first field transmitted is the device address (in this case the node address of the Mint controller). 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, an 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.

Application note Integrated Modbus support AN00198
ABB Motion control products 3
new.abb.com/motion
A typical message frame is shown below.
START
ADDRESS
FUNCTION
DATA
CRC
CHECK
END
8 bits
8 bits
n * 8 bits
16 bits
{delay}
[STX]
[ETX]
[NUL][SOH][NUL][SOH]
Õ ù
{delay}
ADDRESS
8 bits
[STX]
The address field of a RTU message frame contains one character (8 bits). Valid Server device
addresses are in the range of 0 –255 decimal.
When the Server sends its response, it places its own address in the address field of the
response to let the Client know which Server is responding. Address 0 is used for the broadcast
address, which all Server devices recognize.
When configuring a Mint controller for use as a Modbus Server it is therefore advisable to avoid
setting this controller up as Mint Node 0 (note that the Client can only use the broadcast
address for write transactions).
FUNCTION
8 bits
[ETX]
The function code field of a RTU message frame contains one character (8 bits). Valid codes
(from the Client) are in the range of 1 –127 decimal.
When a message is sent from a Client to a Server device the function code field tells the Server
what kind of action to perform. Examples are to read the ON/OFF states of a group of discrete
inputs; to read the data contents of a group of registers; to read the diagnostic status of the
Server or to write to designated registers.
When the Server responds to the Client, 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 Server simply echoes the original function code. For an
exception response, the Server returns a code that is equivalent to the original function code
with its most–significant bit set to a logic 1.
DATA
n * 8 bits
[NUL][SOH][NUL][SOH]
The data field is constructed using sets of two hexadecimal digits, in the range of 00 to FF
hexadecimal that are then packed into a single ASCII character. The data field of messages
sent from a Client to Server devices contains additional information which the Server 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 Client requests a Server to read a group of holding registers (function code
03), the data field specifies the starting register and how many registers are to be read. If the
Client writes to a group of registers in the Server (function code 16 decimal), 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 responsefrom a Server to a Client contains the data
requested. If an error occurs, the field contains an exception code that the Client application can
use to determine the next action to be taken.
CRC
CHECK
16 bits
Õ ù
When RTU mode is used for character framing, the error checking field contains two ASCII
characters. The error check characters are the result of a Cyclic Redundancy Check (CRC)
calculation that is performed on the message contents.
The CRC characters are appended to the message as the last field.

Application note Integrated Modbus support AN00198
ABB Motion control products 4
new.abb.com/motion
Exception responses
When a Client device sends a query to a Server device it expects a normal response. One of four possible events can occur
from the Client’s query:
•If the Server device receives the query without a communication error, and can handle the query normally, it returns a
normal response.
•If the Server does not receive the query due to a communication error, no response is returned. The Client program will
eventually process a timeout condition for the query.
•If the Server receives the query, but detects a communication error (incorrect CRC), no responseis returned. The
Client program will eventually process a timeout condition for the query.
•If the Server receives the query without a communication error, but cannot handle it (for example, if the request is to
read a non–existent register), the Server will return an exception response informing the Client of the nature of the
error.
The exception response message has two fields that differentiate it from a normal response:
Function codefield: In a normal response, the Server echoes the function code of the original query in the function code field of
the response. All function codes have a most–significant bit (MSB) of 0 (their values are all below 80 hexadecimal).
In an exception response, the Server sets the MSB of the function code to 1. This makes the function code value in an
exception response exactly 80 hexadecimal higher than the value would be for a normal response.
With the function code’s MSB set, the Client’s application program can recognize the exception response and can examine the
data field for the exception code.
Data field: In a normal response, the Server may return data or statistics in the data field (any information that was requested in
the query). In an exception response, the Server returns an exception code in the data field. This defines the Server condition
that caused the exception.
An illegal function response is generated if the Client requests a function other than those supported by the interpreter.
Mint specific settings
MicroFlex e190 and MotiFlex e180 are capable of operating as Modbus Clients and/or Servers via Modbus TCP. MicroFlex
e190 can be equipped with a OPT-SIO-1 option card and is also capable of operating as Modbus Server via Modbus RTU.
are only capable of operating as Modbus servers. Both products support Modbus RTU, only
NextMove e100 supports Modbus TCP
Support is provided for the following Modbus Server functions:
•03 –Read holding registers
•04 –Read input registers
•06 –Preset single register
•16 –Preset multiple registers
•23 –Read / write 4x registers
Support is provided for the following Modbus Client functions (only MicroFlex e190 and MotiFlex e180):
•03 –Read holding registers
•04 –Read input registers
•16 –Preset multiple registers

Application note Integrated Modbus support AN00198
ABB Motion control products 5
new.abb.com/motion
Depending on the product, there are two different data areas available that are used for data exchange:
•NetData array
•Comms array
The following table shows the use of the different data areas:
Drive/Controller
Modbus Type
Data area
MicroFlex e190
Modbus TCP Client/Server
NetData
MicroFlex e190 + OPT-SIO-1
Modbus RTU Server
Comms
MotiFlex e180
Modbus TCP Client/Server
NetData
NextMove ESB-2
Modbus RTU
Comms
e100 products
Modbus RTU/TCP
Comms / NetData
(see MODBUSPARAMETER below)
For e100 products we can choose where the data goes set by the Mint keyword MODBUSPARAMETER:
NetData array:
MODBUSPARAMETER(_busSERIAL1, _mpREGISTER_MAPPING) = _rmNET_DATA
Comms array:
MODBUSPARAMETER(_busSERIAL1, _mpREGISTER_MAPPING) = rmCOMMS_ARRAY
This data area has a fixed mapping with respect to how it appears to a Client device as Modbus registers as shown by the table
below (equivalent AC500 addresses are also shown for reference):
Server Modbus
register
AC500 address
Mint Comms array
(Comms=Real, Commsinteger = DWord)
Mint Netdata array
(Netfloat = Real, Netinteger = DWord)
0
%MW0.0
%MD0.0
Invalid
Invalid
Element 0 LSW
Element 0
1
%MW0.1
Invalid
Element 0 MSW
2
%MW0.2
%MD0.1
Element 1 LSW
Element 1
Element 1 LSW
Element 1
3
%MW0.3
Element 1 MSW
Element 1 MSW
4
%MW0.4
%MD0.2
Element 2 LSW
Element 2
Element 2 LSW
Element 2
5
%MW0.5
Element 2 MSW
Element 2 MSW
…
---
---
---
---
---
---
198
%MW0.198
%MD0.99
Element 99 LSW
Element 99
Element 99 LSW
Element 99
199
%MW0.199
Element 99 MSW
Element 99 MSW
200
%MW0.200
%MD0.100
Invalid
Invalid
Element 100 LSW
Element 100
201
%MW0.201
Invalid
Element 100 MSW
202
%MW0.202
%MD0.101
Invalid
Invalid
Element 101 LSW
Element 101
203
%MW0.203
Invalid
Element 101 MSW
…
---
---
---
---
---
---
1996
%MW0.1996
%MD0.998
Invalid
Invalid
Element 998 LSW
Element 998
1997
%MW0.1997
Invalid
Element 998 MSW
1998
%MW0.1998
%MD0.999
Invalid
Invalid
Element 999 LSW
Element 999
1999
%MW0.1999
Invalid
Element 999 MSW
LSW –Least Significant Word : MSW –Most Significant Word
The Mint Comms array provides 99 elements (1-99). If the Client attempts to access Comms element 0 or Comms elements
greater than 99 the Mint controller will return the ‘Invalid Data Address’ Modbus exception packet.
The Mint Netdata array (not supported on NextMove ESB-2) provides 1000 elements (0-999). If the Client attempts to access
Netdata elements greater than 999 the e190/e180 will return the ‘Invalid Data Address’ Modbus exception packet.
Registers are addressed starting at zero. However Mint Comms locations are addressed from 1 –99 (see also Application Note
AN00110) so care should be taken not to try to read or write register 0 on the Mint controller if using Comms instead of
NVLONG.

Application note Integrated Modbus support AN00198
ABB Motion control products 6
new.abb.com/motion
When using Modbus the byte and word order of the Modbus data is important. It is possible to change the settings for both byte
and word order for Client and Server operation in the drives. The default byte and word orders are configured to match the
requirements for communication with other ABB Motion, PLC and HMI products. Some third party Modbus products tend to use
little endian word order so when using a third party Client it may be necessary to adjust this setting in the drive.
Modbus RTU and TCP are also supported as standard on the CP600 and CP600-eco ranges of HMI panels as well as the
AC500 PLC range.
Network topology
Modbus RTU
When using 2-wire RS485 be sure to include 120 ohm terminating resistors between data lines A and B at each end of the
network to avoid data corruption.
When using 4-wire RS422 be sure to include 120 ohm terminating resistors between RX+ and RX- at each end of the network to
avoid data corruption.

Application note Integrated Modbus support AN00198
ABB Motion control products 7
new.abb.com/motion
When using MicroFlex e190 with OPT-SIO-1, the termination could be realized with the dip switches on the option module.
When using MicroFlex e150, the termination could be realized with the dip switches at the front side of the drive
No external resistor is needed.
MicroFlex e190
MicroFlex e150
For MicroFlex e100 and NextMove, the termination must be realized externally.
Modbus TCP
When using Modbus TCP / Ethernet, wire the network in a ‘star’ type configuration using an Ethernet switch between the Client
and the connected Server(s). Straight-through or crossover cables may be used between the devices and the switch. If the
controller is part of an Ethernet Powerlink (EPL) network then it is also necessary to include an EPL Router (part: OPT036-501)
or a MicroFlex e190 / MotiFlex e180 drive acting as an EPL router between the switch and the devices (see Application Note
AN00247 for further details).
Note: AC500 and CP600 products use a non-standard RS232 pinout so be sure to check the relevant product manual before
connecting other serial devices to these products. Failure to observe the correct pinout may result in damage to the connected
device.
Supported connection types
Controller
The table below shows the physical connection possibilities for NextMove products supporting integrated Modbus protocols.
AC500 and CP600 products are included for reference.
Connection Type
NextMove e100
NextMove ESB-2
AC500
AC500 Eco
CP600
RS232
Yes
Yes (by variant)
Yes
No
Yes
2 wire RS485
Yes
No
Yes
Yes
Yes
4 wire RS422
Yes
Yes (by variant)
No
No
Yes
Ethernet
Yes
No
Yes
Yes (by variant)
Yes
Drives
The table below shows the physical connection possibilities for MicroFlex e1x0 and MotiFlex e180 drive products supporting
integrated Modbus protocols.
Connection Type
MicroFlex e100
MicroFlex e150
MicroFlex e190
MotiFlex e180
RS232
No
No
No
No
2 wire RS485
Yes
Yes
Yes (OPT-SIO-1)
No
4 wire RS422
No
Yes
Yes (OPT-SIO-1)
No
Ethernet
Yes
Yes
Yes
Yes

Application note Integrated Modbus support AN00198
ABB Motion control products 8
new.abb.com/motion
Example 1:
Connect MotiFlex e180 (Modbus TCP Client) to MicroFlex e190 (Modbus TCP Server) via Switch or via crossover cable
OR

Application note Integrated Modbus support AN00198
ABB Motion control products 9
new.abb.com/motion
Example 2:
Connect MicroFlex e190 equipped with OPT-SIO-1 option card (Modbus RTU Server) to an external PLC (e.g. AC500 COM2)
Please refer to the OPT-SIO-1 Option Card of MicroFlex e190 Servo Drive Quick installation guide for more information about
how to install the option card.
AC500 COM2
e190 OPT-SIO-1

Application note Integrated Modbus support AN00198
ABB Motion control products 10
new.abb.com/motion
Example 3:
Connect MicroFlex e150 (Modbus RTU Server) to an external PLC (e.g. AC500-eco)
AC500-eco COM2
e150 X6