ModbusNews_Spring2009.pdf

(366 KB) Pobierz

Newsletter

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

different

denominator — between

devices to

different manufacturers...

transfer

discrete/analog

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

applications.

Please join us in celebrating 30 years of success. Modbus

— in gas and oil and substation applications,

manufacturing, building, infrastructure, transportation and

energy.

30 years - still growing and still going strong.

Modbus: Still the Best

Choice for Building

Automation

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.

(continued

on page 3)

News about the World’s Most Popular Industrial Protocol

Member News • MemberNews

Meet Some of Our Members...

Danfoss

is one

of the largest

industrial

companies in

Denmark.

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

savings.

(www.danfoss.com)

Thermokon Sensortechnik

was

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

electrical

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.

(www.eaton.com/electrical)

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

buildings.

(www.thermokon.com)

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: www.modbus.org

Newsletter Editor:

Lenore Tracey

lenore@modbus.org

Organization, Inc.

PO Box 628

Hopkinton, MA 01748 USA

ph +1-508-435-7170

fax +1-508-435-7172

info@modbus.org

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

(ww.rtaautomation.com/products/

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

http://www.rtaautomation.com/products.

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

reasons:

•

Device availability

•

Cost

•

Simplicity, reliability &

supportability

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

Q&A

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

problem?

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 ww.miille.com.

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 (www.kepware.com).

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

header.

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.

Craig:

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

at modbus.control.com/thread/

1236017142

Modbus RTU over Ethernet...

Modbus users & suppliers

get together on the

Modbus Community for:

•

Interactivity

•

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

ww.wireshark.org). 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

frustrating…

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 wireshark.org.

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

legitimate?

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? 192.168.x.xxx (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

server?

Editor’s note: After a long

discussion, the author solved his

problem. Find out how or add your

comments to this thread at

modbus.control.com/thread/

1237510299

Plik z chomika:

TirNaNog

ModbusNews_Spring2009.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: