Regular readers of this list will be well aware of my long running quest to find an industrial communications protocol that is suitable for using
'across the board' i.e. from IP level down to serial connections to field devices.
Commonly used solutions generally do not achieve this. OPC, for example, is an internal windows protocol, it does not take you into field devices
and would perhaps be better described as a 'device driver'. Modbus, Profibus, CAN et al take you from the field level to the controller, but not onto the information highway. Of course Profibus also have their 'industrial ethernet', but the only working example of this glorious
product seems to require so many high priced elements that it just prices itself way out of my market, as does OPC in a way, which appears to me to make life easier for SCADA software producers and force costs onto end users.
Really it should not be too hard to do this, actually I already do using my own protocols. But while discussing this in the past somebody
pointed out to me that MODBUS now has a TCP/IP transport, and like the original protocol this is openly published and royalty free.
Well, I checked this out and found that there is not only a TCP/IP transport for MODBUS queries, but also a messaging protocol. What's more
they have kept things simple so you do not get unreliable bloatware and it should be easy to implement custom gateways such as querying an OMRON PLC from a an OPC SCADA package.
So now I feel like I have received one of those 'earn $2000 a day in your spare time' emails, it sounds too good to be true. Why is everybody not using it? Now while I know a lot of people are using MODBUS on a wide range of products, by and large it has been in use as a async serial based field to controller product. So, does anybody have any success/disaster stories regarding the use of MODBUS frames or messaging over TCP/IP networks?
I have been programming TCP/IP for years, and it LOOKS valid to me, but appearences are often deceptive!
Our customers have used Modbus/TCP to talk to our motion controller. The only examples that I can remember now are with Wonderware. Wonderware calls Modbus/TCP, Modbus Etherent. When I first tried it out it was at a trade show. I took the motion controller to a Wonderware booth and the Wonderware enginer was able to read positions from the motion controller in just a couple minutes. I let a programmer here borrow a newly running Linux system. He took it home and got the demo source code from www.modbus.org. He said it took him two seconds to get it working. I am sure it took longer than that to change the IP address and compile. He was getting 5.5 to 6 millisecond updates on a 200Mhz pentium pro. Our tests here with a real Modicon NOE module shows a 18 millisecond turn around time. Anyway it is reliable and easy to implement. I think it would be foolish not to have this protocol in you bag of tricks and it should be everyones second or backup protocol. In this way many manufactures could have their devices communicate with each other. However, most (80%) of our customers still use our motion controllers with SLC500 which uses a AB proprietory protocol. Another neat item. One of our field engineers was asked how to get a CTC display to talk to our motion controller. We support 7 applications or PLCs over Ethernet now. The customer CTC supported two of those protocols. They selected the SLC500 Ethernet protocol but the other choice was the Modbus/TCP. The communication problem that wasn't.
There are several reasons that more people don't use Modbus/TCP and most of them are bad.
1. It would actually be fairly universal and well understood. This prevents vendors from locking customers into using only their equipment. This is the primary reason.
2. It's cheap to implement and uses commodity networking gear. No $3.00/ft cable or $80.00 connectors and like you say, anybody who wants to can do it. You don't need a $10,000 membership or even to be a voting member in any club. How would
the vendors survive competing on merit alone? And there's no way to keep others from using it. People could even use the existing Ethernet wiring they already have.
3. It wasn't invented here. Modicon does own it and you can't possibly use any protocol from a competitor, unless of course it was mangled and manipulated by at least three major vendors in a cartel^h^h^h^h^hconsortium. How can you ballyhoo it and present it as an enormous advance in sending register values from one end of a wire to the other. It's not new or improved or anything. The marketing people would kill it.
4. It's no good technically. _Everyone_ knows that Ethernet is non-deterministic.
Why, collisions might delay your message by a whole Microsecond. You can only resend 100 times in a typical once per scan update. Never mind that the folks that are saying that are feverishly working to provide _their_ latest
transport, Ethernet. That'll be a lot better but they can't tell you how because it's a secret.
5. It's too limiting, all it can do is pass registers and messages between machines. It won't do RPC's and there's no roadmap to support .NET or any of the office automation api's How can any automation product be any good
if it doesn't require a Microsoft product. There won't be any kickbacks or perks from Redmond. You can run it on just about anything.
There are a few better reasons:
It's not too standardized because not too many people use it yet.
There's not a lot of compatible equipment yet.
Both of these are mostly because of the other reasons above.
I'm using it and it will be the first protocol supported by the Linux PLC. This is also because of the other reasons above.
Curt Wuollet, Owner
Wide Open Technologies.
I liked your reasons, but I was refering to the users, not the hardware vendors! It is about time automation users made vendors listen to what they need!
I would take issue with a couple of points:
> 4. It's no good technically. _Everyone_ knows that Ethernet is
> Why, collisions might delay your message by a whole Microsecond. You can only
> resend 100 times in a typical once per scan update. Never mind that the folks
> that are saying that are feverishly working to provide _their_ latest
> transport, Ethernet. That'll be a lot better but they can't tell you how
> because it's a secret.
The use of TCP does not determine wether the connection is deterministic or not, IP and the underlying transport do. A casual ethernet network is never deterministic per se, but you can include timeouts at a higher level to make it so. Any which way, it is all flawed. The fundamental problem is that synchronous methods such as those used in DP present nightmare problems when scaled into large systems, the system design philosophy must be altered to make it asynchronous, this also implies abandoning the ladder logic scan/cycle paradigm.
> 5. It's too limiting, all it can do is pass registers and messages between
> machines. It won't do RPC's and there's no roadmap to support .NET or any
> of the office automation api's How can any automation product be any good
> if it doesn't require a Microsoft product. There won't be any kickbacks or
> perks from Redmond. You can
Saying Modbus can't call procedures is like saying RPC can't transfer data. Just as you would use a function call in RPC to write data, so you
would use 'virtual' registers in modbus to call functions and get the return values (See Borlands VCL library which overloads reads and writes
to object properties with methods). You can also implement the underlying methods of a DCOM object with modbus calls, you do not need a roadmap.
Let's make a few things clear about DCOM, there is so much confusion.
DCOM is not an extension of COM, it is a transport that carries COM requests back and forth between remote machines. It actually does this using the Open groups RPC (for actually doing the spade work), DNS for mapping net namespace, and LanManager for authorisation.
Now Open Groups RPC is, of course, SUN RPC, it changed its name when SUN handed it over to the open group and made it available to everybody.
DNS is the veritable internet standard produced by Berkeley, MIT, et al, and LanManager was originally an IBM protocoll, extended by Microsoft
but nonetheless in the public domain. DCOM is in fact more of a UNIX protocol than a windows one (A great irony for me is that DCOM revolves
around the use pointers and pointer arrays, yet Visual Basic goes to great lengths to avoid that pointers be used, a case of 'we know how useful pointers are, but they are too powerful to be used by the likes of you').
RPC and DNS are two fundamental services for unix, and LanManager, NT domainset al, have been available for many years on UNIX platforms. DCOM is platform independent and is available on, e.g. Linux. The work of implementing it on *nix platforms (see note at end) was done by Software Ag who were financed by Microsoft, proof, if ever any were needed, that MS MUST make DCOM truly
open if it is to compete with CORBA which has allready entrenched itself in sectors such as telecomms, banking and government were proprietry
solution are simply not accepted (Automation should learn from them, they get their suppliers to work to THEIR advantage).
So where is the problem? Well, DCOM requires so much resources, god knows why, as RPC, DNS and LanManager are pretty light protocolls to implement. Just as DCOM on Windows needs a hefty NT4SP5 with bags of memory, so DCOM on linux requires at least a desktop sized system. I am perplexed as to why this is so.
And this is the crunch. You see we cannot go into the future relying on PLC's and their ladder logic, we need embedded network servers with state
machines and structures software. When I lament not being able to do DCOM on my Linux boxes it is not because DCOM is 'incompatible'with Linux
(it isn't), it is because my Linux boxes are little embedded systems with a bit of flash memory on a DIN rail. My clients can use what the hell they like, I am not in my wildest dreams imaging that e.g. a production manager switches from windows to Linux on his desktop machine, but not even my wildest nightmares imagine me putting NT4SP5 on an 8MB flash 16MB RAM embedded controller, nor do my dreams envisage sticking fully blown PC's all over the place.
I have no problems with providing DCOM objects to my windows clients (or Linux or MAC ones come to that), but DCOM just will not take me out to the
cabinets and remotisezed modules. Modbus will do that, but will also run up the network to a program that is stuffing data into/out of a corporate database.
It could be better, but the problem is that OPC seem to be working with the marketing people at MS rather than the technical people. And they do not seem to care. What they are doing today is not that different to what SUN and other were doing in the telecomms sector 15 years ago, but they had much less powerful kit in those days. OPC, instead of regurgitating roadmaps and going MS sneak prevue cub scout meetings, should be taking the problem by the horns and saying to MS 'how can we simplify this stuff?' Surely a lot of this stuff could be optional? Do we really need to tie ourselves so closely to Network services?
But, also, as they are the only major automation standards group that is not strongly associated with a manufacturer, they could promote modbus, or
something like it, as a protocol at the field level, and allow the translation to DCOM (if required or desired) to take place at any part
of the hierachy. The neat bit would be encapsulting DCOM profiles inside modbus function calls. Alternatively, they could define a simple standard that allows DCOM fuctionality to be extended into the field (he...he... my tongue in the cheek KISS protocol is actually capable of doing that......)
At the end of the day it will be my clients who decide. Modbus and/or other fieldbusses mut be used in the field. I can give windows users objects that can access them directly, or, if they want OPC, they can do it that way, it will cost them more, require more computers instead of embedded boxes and/or more wiring. As suppliers we are better of with OPC (more money, more work), but, most of our customers look at the bottom line, and we frequently win work because we offer simple low cost solutions than work
rather lots of 'modules' with flashly logos.
Automation standards are in a mess, and we will not get this sorted out overnight. Somebody said 'MODBUS is a trick that everybody should have in thier gadget bag'. I think that is a good starting point. Modbus can do everything and go everywhere, except for critical timing, but
architectecturally automation should be working towards limiting synchronicity to local areas where it is strictly necessary (encoders and drives), and be doing it with specialist buses designed for this such as CAN or DP. Do not for 1 minute think that such local buses can scale into large systems.
> It's not too standardized because not too many people use it yet.
I wonder how many people realise that Modbus on TCP/IP is easier to do than on a serial port?
The note: OK, software Ag were not the first to put DCOM on Linux/'nix platforms, I believe quite a few people played around with it, but it never
took off because there is not much call for distributing COM objects around nix applications, and unix programmers have a wealth of well proven methods available to achieve the same goals (including RPC without all the ramatazz).
I believe the scope of the Software Ag porting is to ensure that a quality DCOM implementation exits on *nix, why they want this is outside the scope of this list, but feel free to discuss this with me off list;-)
At 11:36 10/10/00 -0400, Curt Wuollet wrote:
>There are several reasons that more people don't use Modbus/TCP
>and most of them are bad.
>It's not too standardized because not too many people use it yet.
>There's not a lot of compatible equipment yet.
I need to connect a Profibus FMS (actually FDL) network to an Ethernet system, but Siemens (or anyone else) doesn't offer a gateway to do this directly. I don't want to have to try to fit a PC into this application just for a gateway. However, SST does offer their X-Link, which will translate just about anything to anything else, including Profibus FMS. However (again), the only protocols they support on the Ethernet side are AB, GE, and Modbus/TCP (SST refers to it as 'Modicon TCP/IP' - I assume this
is the same?).
If I use an X-Link, I was seriously considering using the Modbus/TCP protocol for the Ethernet side. The reason for this choice would be that I was hoping that as an 'open' protocol, Modbus/TCP would be more likely to have wider acceptance and better long term stability than the purely proprietary systems. I have noticed for example that there seems to be more Modbus-Ethernet gateways than any other type. Stability is an important consideration as I expect to see major changes in the industrial network Ethernet market in the future and I don't want to have to keep re-engineering this system.
I don't have any Modicon PLCs, but it since most of the PLCs I need to connect to are Siemens (with a few AB and Omron - but I can handle them separately), Modbus/TCP sounded like a good neutral format provided I use the SST gateway. I don't need real time control, just monitoring of data. I expect this to take place in a regular poll/respond cycle. There are
potentially a lot of different nodes, but the demand on each one is fairly low.
My specific questions are as follows:
1) How widely used is Modbus/TCP? Is it being accepted on a large scale by anyone outside Modicon?
2) I need an OPC server at the other end of the Ethernet connection. Whose OPC servers could you recommend? I need to potentially (long term) connect several hundred PLCs via several dozen gateways.
3) Are there any good references on how it works? I have downloaded the Modbus and Modbus/TCP specifications from the Modicon and also combed through the Modbus user's group web site (http://www.modbus.org/). Do you have any other suggestions?
4) Is there something I am not taking into consideration?
London, Ont. Canada
> My specific questions are as follows:
> 1) How widely used is Modbus/TCP? Is it being accepted on a large
> scale by anyone outside Modicon?
More like several small scales. It seems to be a popular choice for independents.
> 2) I need an OPC server at the other end of the Ethernet connection.
> Whose OPC servers could you recommend? I need to potentially (long term)
> connect several hundred PLCs via several dozen gateways.
I can't see using an "Open" protocol with a Microsoft controlled API in hopes that it won't change whenever they want to force upgrades. In any case I don't use any MS products so I can't help you there.
> 3) Are there any good references on how it works? I have downloaded
> the Modbus and Modbus/TCP specifications from the Modicon and also combed
> through the Modbus user's group web site (http://www.modbus.org/). Do you
> have any other suggestions?
Read the Modbus spec and then the Modbus/TCP spec for the differences(few). After that, it's simply BSD style socket programming. Once you establish a socket connection it is simply building the message and writing it to the socket, and reading from the socket and parsing the message. Everything below this level is how TCP/IP works on your platform. On Linux, TCP/IP works very well and is a classical implementation so any good networking text will help. It's not very difficult, it looks complicated but it's almost all boilerplate that you can copy from any socket program.
> 4) Is there something I am not taking into consideration?
I don't think so, it's really just Modbus on TCP/IP in the simplest way possible.
> After that, it's simply BSD style socket programming. Once you establish
> a socket connection it is simply building the message and writing it to
> the socket, and reading from the socket and parsing the message.
> Everything below this level is how TCP/IP works on your platform. On
> Linux, TCP/IP works very well and is a classical implementation so any
> good networking text will help. It's not very difficult, it looks
> complicated but it's almost all boilerplate that you can copy from
> any socket program.
I keep forgetting, but one day I promise a will post a code snippet that demonstrates how easily one can use TCP/IP sockets with Python. I started using python to experiment, but as the wrappers are close to the underlying calls, and python is
precompiled the performance is very good, and I have used it in production with great success.
A combination of socket and select objects is a very simple way of dealing with multiple clients, and as far as TCP/IP connections are concerned, it works the same on all platforms (yep, unmodified socket code that works on both Linux and Windows!).
Well, after the several posts on this topic, I felt a fairly technical post discussing a couple of intricacies of Modbus/TCP was needed. So here goes:
Modbus/TCP is well done for normal operations. However, a protocol must be judged not only on its behavior when all is going well, but also its
behavior when bad things happen. Modbus/TCP depends totally upon the behaviors of TCP when bad things happen. And, for many control
applications, TCP does not behave in a stellar fashion.
(Note the specific reference is specifically to TCP, one of many protocols in the TCP/IP suite. Modbus/TCP is a TCP specific application protocol.)
If data is lost (i.e., the physical layer -- most people assume Ethernet as a Physical layer -- starts losing frames) TCP will do any of several things, depending upon the details and variations of implementations of the TCP/IP stack and the application design. If the application has not sent any other Modbus packets and is quietly waiting on the reply, TCP will eventually time
out after many seconds, and retransmit the lost packet. This delay can be a very long time and not reported to the application until, after multiple retries all fail, TCP will close the connection and report the fault to the application. If the physical layer outage was temporary, say one frame, the delay can still be many seconds before recovery is attempted.
If the application is continuing to send Modbus packets (either additional commands or its own retries of the original), some implementations of TCP will add the new packets to the lost packet and retransmit them all, consuming network bandwidth in the retransmission of all bytes that have not been acknowledged at the time more need to be sent. Again, these under-the-cover retries will continue for a while until the connection
fails, or until the TCP transmit buffers fill and the application program will suddenly finds itself blocked in the "send()" function -- a condition not too easily tested and not always planned for by the application. This may or may not be a problem to the application. If the physical layer outage was temporary, the delay may be minimal and recovery swift.
However, the other case (application continues to send, but TCP chooses to not retransmit unacknowledged data and just sends the new data) TCP eventually times out on the unacknowledged (lost) packet and then, in one of the recognized limits of TCP, must retransmit ALL of the data from the first byte of the first lost packet through all that have been transmitted in order to recover from lost data. Thus, many Modbus Packets could have to be retransmitted, consuming network bandwidth, in order to recover from the
earlier lost packet. In the best case, TCP eventually gets all the packets delivered and the application gets its data, though not at the time it expected. Sadly, if many of the packets were polls for the same registers over and over (a very common usage), considerable network bandwidth will be wasted delivering redundant or worse, *old* data. Repeated, cyclic polling
for data is not TCP's best suite.
In all of the above cases, considerable time (several to many seconds) and possible network bandwidth can be wasted without any indication or choice to the application. By the way, the above discussion applies to *all* application protocols over TCP.
The issues with TCP are not the only problem with Modbus/TCP when bad things happen.
If a bad command or other problem is found by the application while interpreting a Modbus packet, there is only one recovery method: close the
TCP connection and open up another one. The "Open Modbus/TCP Specification" from Modicon specifically states this in several places. Further, it encourages all server devices to have extra resources available to allow multiple TCP connections to be in various states of open and close. And this is true even in the case that the server operates with only one active
connection at a time. This can amount to a significant cost to a small Modbus/TCP embedded node.
Remember for a moment, Modbus RTU is a strong and successful serial protocol with error recovery and detection of packet boundaries depending upon tight timing constraints. (Yes, these times are often ignored by various devices, but only at the cost of reduced robustness.) Since TCP delivers a continuous byte stream with no packetization, all of this timing is lost when Modbus RTU is converted to Modbus/TCP. Thus, any problems that could be a bad packet must be handled via a reset of the TCP link.
These issues arise only from using TCP as a transport. Let's not forget that for activities other than accessing registers, Modbus in any of its forms leaves some things to be desired. You can see some of this work at the "Object Messaging Specification for the Modbus/TCP Protocol" done for Groupe Schneider and available, along with the serial Modbus and Modbus/TCP specs, at
So, Modbus is well done. For its original purposes (polling of register data, especially serially with tight timing constraints) it is still an outstanding protocol that I have recommended to folks many times, including on this forum. As Modbus has been moved to later flavors, things are a little less well done, though it still meets a very wide range of
applications with excellence. Unfortunately, Modbus's application strength (repeated reading of register data) is exactly the case where TCP is not the transport of choice, so Modbus/TCP is not quite the optimum it appears, at least when bad things happen.
(Now Modbus over UDP would be an interesting discussion; but this post is already much too long. Anybody want a discussion of how UDP behaves when bad things happen and how better to do repeated cyclic polling of register data using the TCP/IP suite?)
But, as was noted in another recent post, there probably are no panaceas that solve all network problems for all plants. And there probably never
will be any. Modbus/TCP in particular, has some characteristics in its error handling and recovery that must be considered carefully when it is being considered for any particular application.
Oh, for the folks who like to argue about Ethernet's non-determinism and its impact, the variability by TCP as described here for these cases is vastly larger than the variability of any Ethernet. Yet the impact of TCP/IP stack
processing variability somehow gets ignored in the Ethernet determinism discussion.
Steven B. Cliff title: VP, Research & Development
Control Technology, Inc. email: firstname.lastname@example.org
5734 Middlebrook Pike web: http://www.controltechnology.com
PO Box 59003 voice: (865) 584-0449 x220
Knoxville, TN 37950 fax: (865) 584-5720
List Management Account wrote:
> Well, after the several posts on this topic, I felt a fairly technical post
> discussing a couple of intricacies of Modbus/TCP was needed. So here goes:
Lot of very good points about TCP recovery problems, but of course TCP does have packet numbering and marshalling facilities so replies do not arrive blindly out of order.
.....end of snip.......
> (Now Modbus over UDP would be an interesting discussion; but this post is
> already much too long. Anybody want a discussion of how UDP behaves when
> bad things happen and how better to do repeated cyclic polling of register
> data using the TCP/IP suite?)
Yes. I well know the problems of TCP having encountered them first hand, on the other hand in Supervision/Control/SCADA type applications one does not need deterministic timing, and the drops-outs that occur when a socket is closed on error are not a problem either. On the other hand IP routing (WAN networking) is an important feature in such applications. Does UDP improve things? One issue that springs to mind is authorising the connection (important if you really do have a
WAN). This is not so easy with UDP.
> But, as was noted in another recent post, there probably are no panaceas
> that solve all network problems for all plants. And there probably never
> will be any. Modbus/TCP in particular, has some characteristics in its
> error handling and recovery that must be considered carefully when it is
> being considered for any particular application.
Deterministic/WAN. Conflicting requirements. ATM is able to solve this sort of problem, but at a price still out of budget.
Modbus on TCP/IP is a good SCADA method, ANYTHING on TCP is not good for deterministic performance.
What about adding MODBUS on ethernet?
> Oh, for the folks who like to argue about Ethernet's non-determinism and its
> impact, the variability by TCP as described here for these cases is vastly
> larger than the variability of any Ethernet. Yet the impact of TCP/IP stack
> processing variability somehow gets ignored in the Ethernet determinism
I don't think anybody was implying that TCP is more deterministic, I think it is the DP folks lamenting anything that is not.
No argument on any of the technical points. The fact remains that TCP/IP works amazingly well, almost all of the time. I wish we had a really
excellent free and open protocol designed on top of UDP. Such a proto would have design decisions not unlike those the TCP developers faced
but with different priorities. And sending only deltas makes a lot more sense, but we have to live with the register paradigm for a while yet.
There are hard realtime versions of at least UDP available for Linux which will eventually be used in automation. And, yes those bad things can happen. However, it has become commonplace to do automation and control work with tools and especially software that is much less reliable than the internet protocols. I would bet that your desktop OS fails more frequently than your Ethernet connection using those protos.
Taken in perspective, there are typically several more risky links in the chain. In my view, using secret, proprietary software that hasn't and can't be verified to any significant extent is much more risky than using well known and and widely tested open software that has been tested and scrutinized by more people than are employed in the entire automation industry. Your analysis is the result of such scrutiny. How many
"private" protocols have been characterized and analyzed to that extent? I found more bugs in one proprietary implementation than have been
dredged up by millions of users of the Linux IP stack for example. And, I'll bet you a cup of coffee that they are still there. It's a clear case of the mote and the beam when people pick on the protos to the nth degree and then use Windows for example, to build automation. For some reason, frequent failures of a whole system are
more acceptable than very rare and recoverable failures of a protocol.
If all the major vendors would agree on a common protocol, that proto would stand a chance of being as well understood and highly developed
as any member of the internet suite. I'm not demanding they give up their redundant competitive offerings, simply agree on _one_ that can be open, free, and universal to solve the interoperability problems and tie diverse equipment together. The savings in resources for all the vendors and the integrators and the customers in eliminating all this duplication of effort would be astounding. This will _never_ happen as they just don't get it.
In the meantime, Modbus/TCP is a pragmatic interim solution pending the development of a better, more open, designed for IP solution.
My biggest fear is that, by then, there will be so many half baked proprietary Ethernet protocols that a real solution will be lost in the noise.
Curt Wuollet, Owner
Wide Open Technologies
> Well, after the several posts on this topic, I felt a fairly technical
> post discussing a couple of intricacies of Modbus/TCP was needed. So
> here goes:
I think the discussion here was very good and pertinent.
> If the application has not sent any other Modbus packets and is
> quietly waiting on the reply, TCP will eventually time out after
> many seconds, and retransmit the lost packet. This delay can be a
> very long time and not reported to the application until, after
> multiple retries all fail, TCP will close the connection and report
> the fault to the application.
This behavior on the part of TCP is because of its roots in very early computer systems where everything was a 'stream' of data, not discrete packets. TCP had to look for idle periods in the stream in order to make an assumption about when to transmit the data to avoid breaking the streams apart too much. The result is that most TCP timeouts are much too large to be useful in a real-time environment. Some systems will allow these timeouts to be modified but it can take
quite a bit of detective work to find out how it is done.
Also, in some applications is it very important to know that the virtual link with the remote is up even if you are not using the link right now. TCP/IP stacks implement this via a "keep-alive" timer that is typically set to such a large value that it makes it nearly useless. Again, it can take quite a bit of detective work to find out
how to change this setting on some systems.
> If a bad command or other problem is found by the application while
> interpreting a Modbus packet, there is only one recovery method: close
> the TCP connection and open up another one. The "Open Modbus/TCP
> Specification" from Modicon specifically states this in several
> places. Further, it encourages all server devices to have extra
> resources available to allow multiple TCP connections to be in various
> states of open and close. And this is true even in the case that the
> server operates with only one active connection at a time. This can
> amount to a significant cost to a small Modbus/TCP embedded node.
This is typically a problem with all "trivial" protocols. They are so simple that the functions that should be handled transparently by the
network stack or the application protocol have to be pushed into the application program. While you may not have a protocol for every layer in the 7 layer stack, if the function is not provided, someone will have to do the function and that is typically the application program.
> (Now Modbus over UDP would be an interesting discussion; but this post
> is already much too long. Anybody want a discussion of how UDP
> behaves when bad things happen and how better to do repeated cyclic
> polling of register data using the TCP/IP suite?)
Yes. There are in fact transport protocols that are better suited for IA but they suffer 4 primary drawbacks:
1. They are not supported by Microsoft
2. They are not widely implemented
3. They cannot be used easily on the Internet
4. They take more than a day to implement
Technical considerations aside, these factors (Particularly #2 and #3) are the primary considerations today. The technical merits really
don't matter that much anymore.
> Oh, for the folks who like to argue about Ethernet's non-determinism
> and its impact, the variability by TCP as described here for these
> cases is vastly larger than the variability of any Ethernet. Yet the
> impact of TCP/IP stack processing variability somehow gets ignored in
> the Ethernet determinism discussion.
Well said. Focusing on determinism is a red herring. With Ethernet speeds increasing the probabilistic issue with Ethernet is quickly
overcome by raw bandwidth. Protocols above data link are much more important today than the wire.
Sounds like your saying that if the Ethernet is broken the MODBUS/TCP protocol won't work. That makes sense.
The point being that Ethernet provides low level functions to retransmit lost or damaged packets (possibly due to collisions) so if the Ethernet is
working properly TCP should not be experiancing any of the problems you have identified.
If however the link went via the Internet, lost packets are typically very common and only TCP is there to fix this.
The moral of the story seems to be that MODBUS/TCP may not work very well over a poor Internet connection but should be just fine over a dedicated pure Ethernet connection.
There has also been some comments on the list lately about possible other "really open protocols" and also about use of UDP packets. One possible protocol is ANSI/ASHRAE Standard 135-1995 BACnet. This is about as open and
independent as they get, can run across RS485, Arcnet, LONWorks, Ethernet and RS232 links and is designed specifically for the building controls
industry by the building controls industry generally (including users). See
http://www.bacnet.org/ for more details. Note, I'm not suggesting that it could be used for all industrial control applications but for those trying to develop open standards based controllers it may be worth considering.
BACnet also runs across the Internet using UDP packets rather than TCP. See
http://www.bacnet.org/Tutorial/BACnetIP/default.html for a more detailed discussion including why they used UDP rather than TCP.
Magenta Communications Pty Ltd
121 King Street,
Melbourne, VIC 3000
Peter Whalley wrote:
> Sounds like your saying that if the Ethernet is broken the MODBUS/TCP
> protocol won't work.
> That makes sense.
I think the point is that TCP, being designed to try and maintain connections over WANS, can be quite slow before giving up, and you can receive packets after some delay. I have been thinking about this UDP thing and it would seem to offer the advantage that the application can easily decide on timeouts and how to behave, but I have also been thinking that MODBUS/TCP packets could quite easily be sent as UDP packets in the same format, i.e. make it optional.
But authourisation/protection is an issue, true automation does not require security, but it does need a bit of protection, if nothing else to guard against mistakes or over confident operators. SCADA on WAN/PSTN does need security, but that sort of app would be quite happy with TCP, so a simple challange/reply pair can authorise the connection for life.