(366 KB) Pobierz
Spring 2009
Modbus Protocol
Celebrates 30 Years
The Modbus Protocol messaging structure was developed
by Modicon in 1979. Used to establish client/server
communication between intelligent devices, it is the most
widely used network protocol in the industrial
manufacturing environment. It has been implemented by
hundreds of
vendors on
Modbus remains a lingua
thousands of
franca — or common
denominator — between
devices to
different manufacturers...
I/O and register data between control devices. Industry
analysts have reported over 7 million Modbus nodes in
North America and Europe alone.
Why does Modbus remain so popular? Its simplicity is
compelling: Modbus development costs are exceptionally
low; minimum hardware is required; and development is
easy under any operating system. There are no exotic
chipsets required and one can use standard PC Ethernet
cards to talk to a Modbus device. As an open protocol,
the specification is available free of charge for download,
and there are no subsequent licensing fees required for
using Modbus or Modbus TCP/IP protocols.
Today there are a multitude of Modbus devices available.
Interoperability among different vendors’ devices and
compatibility with a large installed base of Modbus-
compatible devices makes Modbus an excellent choice.
The Modbus Organization has listed almost a thousand
Modbus devices in its searchable online device directory
for users to identify the right Modbus devices for their
Please join us in celebrating 30 years of success. Modbus
— in gas and oil and substation applications,
manufacturing, building, infrastructure, transportation and
30 years - still growing and still going strong.
Modbus: Still the Best
Choice for Building
John Rinaldi, Real Time Automation
Unless we’re successful or lucky enough to live in a grass
hut in Tahiti, all of us live our lives in one building or
another. As you would expect, those buildings are
increasingly automated. Modbus and Modbus TCP
make up a great deal of that automation infrastructure,
accounting for the vast majority of low-level sensors
and devices.
No matter if the building is an office
complex, restaurant, government
office, or automobile service station,
there are multiple control systems
with multitudes of controllers,
sensors, and actuators at work. You
have everything from fire control,
elevators, heating, cooling, and
lighting to roof top ventilators,
exhaust systems, and sub metering of water, electricity,
and gas. In light industry you might have controls and
sensors for pneumatics, water quality, and electronic
filtering. The list is truly endless.
If you look, you’ll probably find Modbus TCP and
Modbus RTU devices at the heart of many of these
systems. The reason is simple: Modbus is the most
widely supported, easiest to implement and easiest to
understand open network in the world today. That
means there are thousands of tested and cost-effective
devices for building automation integrators to choose
from. It’s been that way for a number of years and it
won’t change anytime soon.
Some still argue that Modbus’ dominance will change in
the future. They say that devices with more sophisticated
interfaces like BACnet, Lonworks and others will replace
Modbus-enabled devices. I don’t think so.
on page 3)
News about the World’s Most Popular Industrial Protocol
Member News • MemberNews
Meet Some of Our Members...
is one
of the largest
companies in
Danfoss serves
the industrial automation market with
products such as solenoid valves,
sensors, transmitters and switches for
pressure or temperature. The
company’s products can be found in
many industries requiring state-of-the-
art technology, such as industrial boilers
and district heating, hydraulics, power
generation, and marine applications.
Since 1968 Danfoss Drives has been
dedicated to developing VLT® variable
frequency drives to control speed,
torque, acceleration, synchronization,
positioning, and the overall
performance of AC motors. The
reliable and innovative VLT® drives are
designed to support any automation
application and provide major energy
Thermokon Sensortechnik
founded in 1987 with the production
of special sensors for the heating
industry. Over the years, the product
line has extended to include air quality,
Eaton Corporation’s
business is a global leader in electrical
control, power distribution,
uninterruptible power supply and
industrial automation products and
services. Eaton’s global electrical brands,
including Cutler-Hammer®,
Powerware®, Holec® and MEM®,
provide customer-driven PowerChain
Management™ solutions to serve the
power system needs of the industrial,
institutional, government, utility,
commercial, residential, IT, mission-
critical, and OEM markets worldwide.
Eaton offers an exceptional array of
equipment, tools, and services to reduce
energy consumption and leave a smaller
footprint on the world’s environment.
humidity, light, and occupancy sensors.
At its location in Mittenaar,
Thermokon is supported by 70
dedicated employees; worldwide sales
and service are offered by qualified
system and distribution partners.
Thermokon offers various sensors and
operator panels that communicate
using Modbus.
Thermokon is also a founding
member of the EnOcean Alliance, a
consortium of companies working to
further develop and promote self-
powered wireless monitoring and
control systems for sustainable
Shouldn’t your company
be a member?
Modbus Newsletter
This is the newsletter of the Modbus
Organization, the international non-
profit organization devoted to the
evolution and support of the Modbus
protocols. For more information about
membership and other services, please
refer to our website:
Newsletter Editor:
Lenore Tracey
Copyright 2009 by the Modbus
Organization, Inc.
PO Box 628
Hopkinton, MA 01748 USA
ph +1-508-435-7170
fax +1-508-435-7172
The Modbus Organization Mission
The Modbus Organization, Inc. is a group of independent users and suppliers of
automation devices that seeks to drive the adoption of the Modbus communica-
tion protocol suite and the evolution to address architectures for distributed
automation systems across multiple market segments. Modbus Organization also
provides the infrastructure to obtain and share information about the protocols,
their application, and certification to simplify implementation by users resulting in
reduced costs.
Member News • MemberNews
Modbus in Building Automation,
I agree that each of those other options
are attractive. They are attractive for
lots of reasons, but in the end Modbus
still provides the fastest time to market
and still brings the most bang for the
buck for building automation system
developers and product developers.
Not only does it keep their BOM
(build of materials) cost low, it requires
the smallest amount of engineering
resources and is the easiest to interface
to higher-level control and information
systems through those Ethernet,
BACnet, and Lon protocols.
Our company recently integrated a vast
number of Modbus RTU devices in an
energy application for a company in
Singapore. The requirements for this
building automation system included
sub-metering of power meters
throughout a four-story medical
research lab, and controlling many of
the building services with small
programmable controllers
(Telemecanique Twido™ ) The data
then needed to be integrated into their
Johnson Control Metasys®.
The system integrator for this project
chose Modbus RTU as the sensor
network for his building automation
system for three important reasons:
• Device Availability – There are an
enormous number of low-cost power
meters and PLCs that support Modbus
RTU communications.
• Cost – Lon-, Ethernet- and BACnet-
cont’d from page 1
the data in the Metasys HMI screens.
After careful consideration, the
integrator selected Real Time
Automation’s Modbus RTU to
BACnet Device Converter module
460/mmbs.html). This module
extracted the Modbus Register data
from all the power meters and Twido
PLCs, appropriately scaled each data
point, and combined the ancillary data
for each point.
The project was so successful that two
additional buildings will go online with
the identical system over the next
several months. Real Time
Automation’s Modbus RTU to
BACnet Device Converter module is
part of the company’s complete line
of Modbus Device Converters.
Integration challenges are typical for
many building automation system
integrators. Modbus continues to be
the best choice for low-level
automation devices. As in this
application, system integrators are
finding that not only do they get a vast
choice of possible devices, they find
low-cost solutions and exceptional
device converters with the ability to
interface easily to high-level building
control systems.
John Rinaldi founded Real Time Automation
in 1988. To learn more about the company’s
products and services, visit
enabled devices were substantially more
expensive, sometimes as much as five
times the cost. Ethernet devices also
required the addition of switches. Even
though switches are now a commodity
item, they still contribute to overall
project cost.
• Simplicity, reliability, and
supportability – Modbus RTU devices
are well understood, easily integrated,
and supportable.
Integration of the Modbus RTU
devices was a key consideration for the
system integrator on this project. The
selected devices had to extract Modbus
data from a large number of devices,
The system integrator
chose Modbus RTU as the
sensor network for his
building automation system
for three important
Device availability
Simplicity, reliability &
scale each register, and combine it with
the ancillary string data required to fully
identify each point. This ancillary data
included data strings such as the Tag
name, unit identifier, and other
descriptive data needed to fully present
Modbus-IDA Discussion Forums
Modbus Discussion
Craig posed the following question:
I have a controller that uses Modbus
RTU over Ethernet. How can I get a
touch panel that has Modbus TCP to
communicate with this controller? Am
I going to need a third-party device or
do I need a new driver to be written?
Jerry Miille replied:
Well you might need a new driver and
you might need some additional
hardware — it “depends.”
The devil is always in the details, so you
need to define what you mean by
Modbus RTU over Ethernet. Is this a
“serial port tunneling” application
where Modbus RTU packets are
delivered inside a TCP or UDP
connection? If so is it TCP or UDP
packets? Is your touch panel a Modbus
TCP client or a server?
Also, you need to consider the
performance issues like how fast do
you need this to work, what happens if
there is a communication failure, could
your plant “blow up” if there is a
Modbus TCP is almost a standard and
is well supported by many companies.
There are several “bridges” that can
make the Modbus TCP to Modbus
RTU conversion for you. They differ in
what functions they can perform and,
of course, in what they cost.
Lots of questions for you, and the best
starting point might be for a direct
conversation with potential vendors of
this type of equipment. You can
contact me directly if you choose. My
name and phone number are on our
web site
Manikandan suggested:
You can use a Modbus Gateway to
convert Modbus RTU to Modbus
TCP. ...Many third-party gateways like
Moxa, ADAM, etc. are readily available
and can reduce your development time.
From the Modbus Discussion Forum…
Fred Loveless commented:
Modbus over Ethernet is usually
Modbus RTU encapsulation in an
Ethernet packet. Modbus TCP is
Modbus with a special header and it
does not use the checksum that
Modbus RTU does. You could easily
talk to the device using a serial-to-
Ethernet converter, using a serial driver
to go serial to the converter and then
out to the device.
You could also use Kepware’s Modbus
serial driver with Ethernet
encapsulation to connect directly to the
device (
Craig responded:
So you’re saying if I use a serial RTU
driver and go through a RTU to TCP
convertor I should be good?
From Fred Loveless:
Yes, as long as it is not adding a
Modbus Ethernet header and footer to
the packet. You want a raw TCP/IP
KirkC disagreed:
That won’t work, Craig. If you want to
encapsulate Modbus RTU serial in a
TCP or UDP packet, you need a serial
device server, not a Modbus RTU to
Modbus TCP converter. Most serial
device servers will come with software
that will let you create a virtual COM
port on a PC. With that you can use
most any Modbus RTU driver. But
Kepware’s OPC driver, for example,
lets you directly create a channel to the
serial device server using either TCP or
UDP encapsulation. If your master is
not a PC, you can use two serial device
servers, back to back.
Basically what I have is a touch panel
(HMI) that has a Modbus RTU driver
in it. If I run this through a standard
serial-to-Ethernet converter would I
get RTU over Ethernet? If so has
anyone done this before and, if so, do
you have a recommendations on a
converter to use?
Fred Loveless:
Yes, that should work. The serial-to-
Ethernet converter will be configured
to connect the IP of the device that is
Modbus RTU over Ethernet.
Forgot to mention that this is what our
Modbus RTU Serial driver does when
you enable Ethernet connection. It
wraps the RTU packet in a simple
Ethernet header and footer. When it
gets to the serial-to-Ethernet converter
the header and footer are stripped off,
and the RTU message goes to the
RTU. The RTU responds and the
message goes to the serial side. A
header and footer are placed around it
and sent back to the driver.
We also have customers that have done
this in reverse, i.e. the master on the
serial side sends the RTU request; it is
wrapped by a header and footer. The
RTU receives the request, responds,
and so on. In this process there is
nothing special done in the
communications driver.
Add your commects to this thread
Modbus RTU over Ethernet...
Modbus users & suppliers
get together on the
Modbus Community for:
Knowledge aggregation
Contact with Modbus
users and suppliers
Discussion supported by...
Modbus Discussion
More from the Modbus Discussion Forum…
Monitoring TCP Traffic between
Two Modbus Devices...
Mikey asked:
I’ve got a small network setup at a
customer site: wireless modem, Linksys
router, and then a Modbus controller
with three slaves. One of the slaves is
not communicating with the master —
no response is the error code I get on
the master. I have used a Modbus
TCP/IP tool and have verified that the
slave is transmitting the data, so I
suspect the controller.
I’d like to connect my laptop again as a
node, and just watch the traffic between
my controller’s attempted queries (like a
third-party observer) to try and
pinpoint the problem. Are there any
software tools out there that can do
that (i.e., monitor traffic between other
devices, NOT have your PC simulate
master and or slave)? I’ve tried
Wireshark, but I can only seem to get it
to read traffic to and from my laptop.
Paul Wacker suggested:
A useful tool to diagnose problems on
Ethernet networks is Wireshark
(formerly Ethereal, see It will allow you to
see requests, responses, and data within
these messages.
To connect your laptop as a node and
see this traffic, you may need some
extra hardware. Remember that
Ethernet switches segment traffic, so
even if you connect your laptop to the
switch ports on the router, you won’t
see unicast (point-to-point) traffic of
other devices.
You’ll need to find an Ethernet hub or
a managed switch that supports port
mirroring. This will let you eavesdrop
on the connected devices.
Further from Mikey:
I’ve got a Sixnet managed remote
access switch that I am connecting on
the LAN as well. I configured the port
mirroring, but I still can’t see the traffic.
Am I missing something else? I’ve tried
Wireshark with promiscuous mode
both on and off: no luck. Very
Paul Wacker:
First, make sure you’ve set up port
mirroring properly. You’ll need to select
which port(s) you would like to listen
to, and which port you would like to
monitor on. I would suggest that you
monitor Tx/Rx on your Modbus TCP
slave, and then connect your laptop/PC
to the monitoring port.
As for Wireshark: If this is your first
time using it, try some packet captures
with your laptop/PC connected to
other devices, to make sure you have it
working. If you have multiple network
adapters on your laptop/PC, like wired
and wireless, make sure you’re selecting
the right interface. There is a lot of
great information at
Carl Ellis asked more questions:
...What did you use to see the slave
response? What did the response look
like? When you used the other tools,
were you unable to see any traffic or
just a lack of message response from
slave in question? Using the other tools,
could you see responses from
functioning slaves?
From Mikey:
Let me clarify. I cannot get my Modbus
master to communicate with the slave,
but when I connect my laptop as a
node on the same LAN and run one of
those Modbus TCP tools, I can read/
write to the slave no problem.
I’m trying to watch the communications
(or lack thereof) between the master
and slave to try and understand why the
slave is not responding to the master
(error message is “no response”), when
it does respond to my own prompts
from my laptop.
I have since ordered some hardware to
test. It’s called a barracudatap. Not sure
how this will perform.
From Carl Ellis:
So, the third slave is responding to the
Modbus master tool, but not to the
customer’s Modbus master field client.
Hmmm. If the slave hears its slave ID,
it should return a response, even if it’s
an error code. If your Modbus tool
can get a response, why can’t the
customer’s master?
Does the customer’s Modbus master
display or indicate Modbus error
codes? Could the command from the
master be “incorrect” for whatever
reason and the slave is returning an
error that is not evident?
You’ve checked the query statement in
the customer’s Modbus master and
confirmed that the slave address is
correct? The command function is
How are you tying in your Modbus
tool PC on the LAN? Same switch to
which the customer’s Modbus master is
connected? Or into a switch next to the
slave? Is the cabling between the
customer master and the third slave
used in your master tool test?
Are all devices (Modbus master, three
slaves and temporary PC) on the same
subnet? (or whatever)?
What subnet mask is used on the master
and slaves?
Is this third slave separated from the
master by a router? A managed switch?
Are all three slaves identical devices or
different devices? Does the third slave
have Modbus TCP natively or is its
comm port serial Modbus RTU
connected to the LAN through a serial
Editor’s note: After a long
discussion, the author solved his
problem. Find out how or add your
comments to this thread at
Zgłoś jeśli naruszono regulamin