(495 KB) Pobierz
December 2009
Modbus Device Directory Wastewater Treatment
Approaches 1000 Devices Plant Upgrade
Since launching the Modbus Device Directory in 2003, the
options for identifying appropriate devices for projects
involving Modbus networking have grown almost four-
Users can search for appropriate devices using one filter
for device type and another to limit devices to wired or
wireless (or include both). Device types include AC/DC
drive controls, controllers, HMI hardware or software,
I/O interfaces or modules, sensors, monitoring hardware,
network gateways, and various software product types
such as OPC, SCADA and test and simulation software.
Users can also limit their search to devices that have been
testing for conformance to the Modbus protocol.
Once identifying a selection of products for a project, all
the information necessary to contact the supplier is right at
hand. If the supplier is a Modbus member, a spec. sheet
can be downloaded directly from the device listing.
Check out the directory at
Contact to list your device or for
assistance identifying the right device for your application.
Two Modbus Organization member companies,
ProSoft Technology, Inc.
Schneider Electric
worked with local systems integrators to bring a
wastewater renewal project in Finland to satisfactory
The original automation system from 1992 of the central
wastewater treatment plant of Lapuan Jätevesi Oy was
brought up to date in 2008. The automation renewal
project included the controllers, the SCADA software
and the communication network where nine RadioLinx
industrial Ethernet radios are involved for safe and
reliable transfer of process and control data.
Wastewater treatment is a basic public service that affects
all of us: It is vital to keep our living environment
hygienic and healthy and our watercourses clean. Behind
the scenes, the wastewater treatment process combines
microbiology and chemistry with mechanical
engineering, instrumentation, and automation techniques
that offer high performance in a progressive way.
The central wastewater treatment plant of Lapuan
Shouldn’t your
Jätevesi Oy, a Finnish company located in Lapua, west
of Finland, receives household wastewater and industrial
wastewater from different locations: Atria, Lapuan
Nahka, Kation and Metso Power,
among others. The Lapuan
Jätevesi Oy treats the wastewater
from three locations: Lapua,
Nurmo and Kuortane. It also
maintains municipal wastewater transfer pipelines from
Nurmo and Kuortane to Lapua and the central
wastewater treatment plant in Lapua. This is where the
automation system had to be renewed.
The wastewater treatment
process starts with the primary
treatment where the influent
sewage water is strained to
remove all large objects, and
the oxygen level of the water is increased to facilitate
microbial activity; microbes clean the water by feeding
on its impurities.
(continued on page 5)
Wishing you all peace
and good fortune
in the new year!
News about the World’s Most Popular Industrial Protocol
Member News • MemberNews
Meet Some of Our Members...
( has
developed a reputation for suppling
hardened, cost-effective, Ethernet
networking products for industrial and
rugged applications. Its award-winning
JetPoE and JetBox, flagship products
are widely used for industrial
automation, and outdoor markets such
as IP surveillance, and intelligent
The JetBox series of industrial
networking computers consolidates an
industrial computer, router, managed
switch integrated with the interfaces of
a serial server and digital I/O to make
the network simple. In addition, it is
equipped with value-added software
and a Modbus gateway to adapt to
SCADA systems and make industrial
control easy.
Korenix recently released its new
JetBox 5300-w embedded Linux
computer for front-end industrial
control applications
(profiled on page 6).
Control Solutions
founded in 1995, was a spin-off from
a contract design and product
development company founded in the
late 1980s. The company has been
developing networked control
products since then, specializing in
Since 1984,
Communications & Systems
( specialized in
designing and supplying data
communication equipment, including
wireless network solutions, serial
Modbus-to-Modbus TCP data
gateways, serial device servers
(Ethernet, USB, and WiFi), media
converters, serial communication
controllers, MIL-STD-1553 and
HDLC for avionics test and simulation.
Shouldn’t your company
be a member?
building automation, facility
management, and commercial
automation. Control Solutions offers a
line of off-the-shelf embedded control
products with BACnet, LonWorks,
Modbus, and SNMP connectivity.
Control Solutions also provides
custom programming for standard
hardware and customized hardware
solutions. The company’s engineers
each have over 20 years of experience
in embedded controls technology. All
products are designed and made in the
USA, manufactured under ISO-
The company
recently released a
new resource for graphical
programming for Modbus, BACnet,
LonWorks, and SNMP I/O devices,
which has its own web site:
ACKSYS products are available
through an extensive distributor
network, spanning 20 countries across
the globe.
ACKSYS’s committment to helping its
customers maximize their capital
investments is impressive. The company
bases its work on three major factors:
Choosing components with
guaranteed sustainability and/or
second sources
Checking the obsolescence potential
of strategic products every
six months
Monitoring availability of crucial
parts for at least five years after a
product ceases to be manufactured.
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.
Modbus Discussion
On December 1, Arun wrote:
I am implementing the Modbus
protocol for TCP/IP. Per the TCP/IP
implementation guidelines, I
understood that a slave can handle up
to 16 connections simultaneously.
I believe this can be implemented using
multi-threading concept. But can a slave
device (for example, a PLC or
embedded controller) handle 16 such
threads in parallel without any issues?
And another question, is there any other
way to implement this without multi-
Curt Wuollet replied:
Some can, some can’t, some can’t even
handle one connection decently. Back-
to-back packets will upset some. But
TCP/IP itself handles a lot of the
issues. For the threading, etc. issues, I
suggest you look at any number of
OSS tools and implementations to see
how this is handled in a more or less
standard fashion. It’s pretty much
cookbook stuff and it’s a bad idea to
go rogue. Many, many examples to
look at.
Russ commented:
If by “implementing” you mean rolling
your own, I would first ask “why?”
All slave devices are not created equal,
so do not count on 16 channels on
every one that you end up with. A lot
of slave devices have limited
processing power and will choke, stall,
From the Modbus Discussion Forum…
or die if you attempt to read/write too
Yes, if it supports 16, that means 16
simultaneous, but I would recommend
that you set up your Master device to
use fewer. Normally one for reads and
one for writes, one for data-grams, if
Only look at multi-threading if you
MUST have the extra speed and then
use it on demand if the Slave can
handle it.
M. Griffin suggested:
There is nothing to stop a Modbus
TCP server (slave) from handling as
many simultaneous connections as it
wants. The limitations of any particular
PLC will be due to the internal
software and resource limits. Some
PLCs can only handle four connections
at a time. If the Modbus TCP server is
a program running on a PC, there is no
reason why it couldn’t handle as many
connections as the operating system will
The thing to keep in mind is that as far
as communications are concerned, the
PLC is handling “connections,” not
“threads.” Each client (master) would
make one connection to the PLC. The
client would send a command, wait for
a response, send the next command,
wait for a response, etc. It would then
normally wait some period of time
(the polling rate) before repeating the
sequence of commands. As far as the
communications are concerned, there
should only be one request or response
in the pipeline between each client and
the server.
As far as implementing the software is
concerned, you can do it
synchronously, threaded, or
asynchronously. However, keep in
mind this is an internal software
implementation and does not affect
how the messages go out on the wire
(other than how many simultaneous
conversations you can keep going).
Synchronous software is for where you
need the simplest possible
implementation and don’t need
multiple simultaneous conversations
(e.g., between a client and a couple of
As far as threaded versus asynchronous
is concerned, asynchronous has less
overhead but threaded software is
more common, because that is what
most programmers are familiar with.
All you have said about your
application is that you are
implementing the protocol. It is
difficult therefore to go into much
more detail. If you want to say what
you are doing (client or server,
embedded or on a computer, how
many connections you want to be able
to handle, etc.) then we can talk about
it more if you wish.
Read the rest of this discussion and
add your commects to this thread
Modbus TCP/IP Implementation...
Modbus-IDA Discussion Forums
Modbus Discussion
Modbus Exception on Read
Only Registers...
Enrico posted the following query:
I’m writing source code for a slave
module to connect in Modbus, but
I’m in a little confusion about
exception codes.
What exception code does the unit
transmit if the master attempts to
write a read-only register?
Mark replied:
AFIK, Modbus does not define any
registers as “read only.”
Having said that, I would expect an
exception code 3: illegal data value.
I would be sure to document it for
Mark (
Isaac disagreed:
I beg to differ. The Modbus standard
does define read/write for the 4 basic
data registers in which “input” registers
are read-only. I cite the Modbus
Application Protocol Specification
V1.1b (, p. 6, 4.3
Modbus Data Model.
Modbus bases its data model on a
series of tables that have distinguishing
four primary tables are shown at the top
“Input Registers: 16-bit word; Read-
Only; This type of data can be
provided by an I/O system.”
I would expect Modbus Exception
code 01, Illegal Function, in response
to a write command to a read-only
input register.. For reference, see pg 49,
Modbus Application Protocol
Specification V1.1b.
Modbus Exception Code 01
Meaning: The function code received
in the query is not an allowable action
for the server (or slave). This may be
because the function code is only
applicable to newer devices, and was
More from the Modbus Discussion Forum…
Discretes Input
Single bit
This type of data can
be provided by an I/O
This type of data can
be alterable by an
application program.
This type of data can
be provided by an I/O
This type of data can
be alterable by an
application program.
Single bit
Input Registers
16-bit word
Holding Registers
16-bit word
not implemented in the unit selected. It
could also indicate that the server (or
slave) is in the wrong state to process a
request of this type, for example
because it is unconfigured and is being
asked to return register values.
Mark got back into the discussion:
Differing allowed. I knew when I
posted the reply someone would come
up and say but but but.
It only made sense to me that he was
referring to registers that COULD be
written to marked as “read only” for
his device. This is very common for
slave devices that are not PLCs and use
Modbus as a means to publish status
information of the device.
And that he was using a WRITE
function code.
If he was not using a legal function
code then the reply would be illegal
function and that would be that.
None of the registers that support a
write function are “read only” per the
Mark (
Fred Loveless responded:
Actually Input registers 0x04 and input
coils (discrete inputs) 0x02 are essentialy
read only. You cannot write to them
from a master as there is no function
code to do so. For registers that can be
written to there is no way in the
protocol specification to designate
them as read only.
However, in my job I have seen many
devices that have implemented read-
only data in holding registers. They
simply return an exception code of
0x01 (Illegal Function) if you try to
write to them.
Keep in mind that this is a design
feature that is set by the hardware
manufacturer only.
Fred Loveless
Kepware Technologies
Michael Griffin added:
Read-only registers are called “Input
Registers.” Read-write registers are
called “Holding Registers.” The master
can’t even attempt to write to an input
register, because there is no Modbus
function code to do that. The protocol
avoids the issue altogether by design,
therefore the problem simply doesn’t
arise. That is why there are two types
of registers.
Have a look at the list of Modbus
functions. There are functions for
reading both holding and input
registers, and there are functions for
writing to holding registers. There are
no functions for writing to input
Read the whole thread & add your
thoughts at
Wastewater Treatment Plant Renewal
(continued from page 1)
During this biological treatment phase,
the microbes in the wastewater are
given suitable growing conditions in
terms of temperature, oxygen level,
and nutrition.
The next phase includes chemical
secondary sedimentation, where
aluminum-based chemicals are added
to the water from the biological
treatment to prompt flocculation of
slowly-degrading organic and other
In the last phase, the remaining sludge is
treated by removing water from it. The
water separated from the sludge is
taken back to the beginning of the
treatment process, and the solid sludge
is taken to the Lakeuden Etappi biogas
High-tech automation system
The central wastewater treatment plant
is fully automated. The automation
system from 1992 had reached the end
of the road and it was time to renew
the wastewater treatment plant:
Requirements included.
• Ease of installation and maintenance
• Flexibility to adapt to fast-changing
• Improvement of the overall solution
• Compliance with existing
applications and methodologies
The whole system was renewed in
collaboration with Schneider Electric
and Seinäjoen Teollisuussähkö Ky. “The
old automation system had served its
time. We have been using it every day
for the past 16 years,” Operating Chief
of the plant, Vesa Hahtokari, explains.
The original automation system
involved six controllers from the TSX7
series, with Monitor 77/2 software
environment, and used MAPWAY
communication protocol.
In the new solution, six Modicon
Premium controllers are implemented
with Monitor Pro v7.6 and are using
Modbus TCP/IP
over wireless, using
nine of ProSoft Technology’s
RadioLinx industrial Ethernet radios.
Modbus Application Story
About 2000 process variables are
transiting over the wireless network,
which is also used for programming
and maintenance purposes.
Why wireless?
A total of seven locations had to be
integrated into one single tight network.
The six Modicon controllers are
located in different buildings on the
wastewater treatment plant, and the
plant has two control rooms.
From the user point of view,
the first
advantage of the wireless networking
option was the cost and time savings
for the installation: no need to dig
trenches, no need to clean up existing
cable paths.
From the integrator point of view,
RadioLinx network was “the easiest
part of the implementation. We didn’t
have any problem. These radios are
very easy to configure and mounting
recommendations given by ProSoft
Technology were very clear. Schneider
Electric made some tests in their office
and then explained us how to
implement the wireless network on the
From Schneider Electric’s point of
the engineering of the network
was reduced to a minimum. “When we
started the project, we did not locally
have any specific RF expertise,”
explains Jouni Aarnu, Application Sales
and Key Account Manager, Wood and
BioEnergy, at Schneider Electric
Finland. “We talked to ProSoft
Technology Technical Support
Engineers and provided them with the
basic engineering and layout of the
network. They made some calculations
that were necessary for this type of
application and they provided us with
the recommended lists of accessories
for each radio location: cables, antenna,
lightning protector, etc.”
(continued on page 6)
ProSoft Technology RadioLinx industrial Ethernet radio &
Schneider Electric ConneXium 499 NES 25100
Zgłoś jeśli naruszono regulamin