PLCs and Ethernet LAN


Thread Starter


Can anyone tell me which PLCs (by model # and version) from major vendors that can be connected to Ethernet LAN?

Here's a few that I'm familiar with:
Modicom Momentum M1E has on-board ethernet
Modicom Quantum when using an NOE card-slot module
Modicon Compact sort of, requires a serial/ethernet converter, so it's really
only at 19200.

AB SLC 5/05 has on-board ethernet
AB ControlLogix when using card-slot ethernet module

GE-Fanuc Versamax (CPU5 I believe) has on-board
GE-Fanuc 90-30 OR 90-70, I can't remember which, is available with either on-board, card-slot or you can use both.

Don Zunti, P. Eng.
Delco Automation Canada

david mertens

All siemens S7-300 and S7-400 series PLC's can be connected to ethernet LAN with CP343-1 or CP443-1 communication processor cards.

Marc Leconte

In addition to the ones already listed:
Modicon TSX Premium PLCs can be connected using TSX ETY 410/510 Ethernet modules.
Modicon TSX Micro PLCs can also be connected using TSX ETZ 410/510 but they act as a gateway between ethernet ant the serial terminal port

410 modules provide Ethernet connectivity zith embedded web pages for diagnostics.
In addition, 510 modules support user defined web pages.


Marc Leconte
> Telemecanique TSX57 Premium thru slot mount module.
> Telemecanique TSX37 Micro thru a serial to ethernet converter.

Fernando Capelari - Schneider Brasil

Complete range of Schneider PLC's that has an Ethernet connection available:

- Modicon TSX Quantum with NOE card (10/100Mb and web server)
- Modicon TSX Premium with ETY card (10/100Mb and web server)
- Modicon TSX Micro with ETZ card (10/100Mb and web server)
- Modicon TSX Momentum M1E (10Mb and diagnostics web pages)


ABB PLCs can be connected to Ethernet LAN.
To be more specific ABB has a new system called Industrial IT. In this system there three types of CPUs which can be connected in ethernet. AC800F, AC800M, AC800C. Additionally except this PLCs Freelance2000 with two type of CPU
can also be connected to Ethernet. For further infomation look at "" or send me email.::

Tasos Polychronopoulos
El.Power & control systems
[email protected]
As far as I can tell, ALL of them can be connected to an Ethernet LAN in some
way or another. Some have direct Ethernet ports on them, others need a
gateway/adapter of some sort. Since virtually all have serial ports, you
could conceivably connect to an Ethernet LAN via a serial to Ethernet
convertor. Whether any of these would serve any useful purpose is another

Some use proprietary schemes so that even if you are connected physically it does you no good since you cannot read or write anything to the PLC w/o buying some other piece of their software.

The issue is really what you want to do after you hook it up, and what are you willing to pay, not whether you can or not.

Bob Peterson
I was facinated that no one brought up the fact that, while all these things connect to Ethernet, they still for the most part can't communicate
with each other. Which leaves the value of the Ethernet connection approximately equal to any other propietary bus. It does make talking to
PC's somewhat easier, but Ethernet in this industry has far less meaning than in the rest of the more open world.

Comments ?


William Hullsiek

The same issue pertains to serial (RS-232, RS-422, RS-423, etc.)... Modbus does not talk to DH, or straight ASCII strings.

Adding the Internet Protocol Suite (IP) to the mix, still does not address the issue, because there are various implementations of Modbus/IP, and DH / IP, ad-nauseum.

Ethernet helps generally in a fashion -- because it is more standard than a straight serial connection.

But still, there is no clear standard for application interoperability over networking. (Where examples of the source code is readily
available and can be ported to various operating systems).

- bill hullsiek
Hi Bill

That's why the comment. I think people comfuse the term Ethernet with the benefits derived from the standardization on Ethernet and the internet suite of protocols in general computing. When you say Ethernet in a "normal" context it implies universal connectivity and interoperability. In other words they are thinking about more than just a wire. Of course, some benefit is derived from using commodity hardware, but in the context of automation, the good parts are deliberately left out. So far the use of Ethernet in automation has delivered little of value to the user by design. I could be charitable and say that perhaps the big automation companies don't understand what people are thinking of when they say Ethernet, but I'm afraid the lack of standardization on protocols is no accident. And they advertise as if the benefits were still there. It's simply using a different kind of wire to surround the Tower of Babel. I'll bet the great minds behind this move are still wondering why takeup has been just as slow as when they roll their own. Reminds one of Deming's definition of insanity. I wonder how many other permutations we'll see before they try something different and provide something of value.



Hullsiek, William

From: "Hullsiek, William" <[email protected]>
To: <[email protected]>
Subject: Re: NET: PLCs and Ethernet LAN


I agree -- ethernet is only a small piece of the overall system. As stated before there are 12 layers... of which ethernet is only 1 1/2
eia/tia 568/569, etc. -- represent layer 0 -- the wiring layer.
But yes -- there is the problem of noise and vibration with el-cheapo RJ-45 ethernet 10/100/1000 - switched or buss -- represents layers 1 and implies (IEEE 802.2)
This bothers most control engineers since it is stochastic in nature. ip -- layer 3 and implies layer 2 -- provides routability -- universal connectivity.

udp/tcp/tp0-4 -- transport layer -- reliable delivery of data between systems...
see comer for code and a better description.

operating system layer -- ability to have multiple processes generally, you need a decent operating system in order to have good network connections.
posix, unix, qnx, vertex, linux, rsx, vms, windows 2000 -- work well cpm or ms-dos -- do NOT network well.
real-time executives -- are also problematic.

presentation layer -- ability to encode data over the wire so it can be understood by the other-side. XML or ASCII
-- (I always had a hard-time with asn.1 encoding).

application layer
iec 1131-3 did have support for manufacturing message service

network management layer -- snmp / rmon / cmip -- enough said.

programming layer -- perl, c, c++

configuration mgmt layer -- grep, make, rcss

scripting layer - perl, bourne, vb-script,
-- allows me to quickly tie together apps.

-- bill
There are the inherent issues and substantial horsepower and sophistication are necessary. Yet the standard set by the combination of Ethernet and the impure (per ISO) TCP/IP is unmatched by the "improvements". And since it is ubiquitous and unlikely to go away soon, to have the full open suite of internet protocols in addition to whatever proprietary snake oil is being sold is almost a necessity going forward. And therein lies the problem. The existing PLC model has little capability to actually use world class networking to much advantage. They are often limited to hardwired routines or canned
definite purpose programs that can be run in synchronism with the scan. This limitation partly due to the design and partly to the absence of any user language capable of expressing networking tasks. This will eventually require the type of hardware I am designing now and a model not entirely built around the IO cycle. An OS is indicated when networking, communications, computation and indirect tasks in general form a substantial part of the workload rather than being
tacked on to a scanning engine. I think, for many applications, we are at the point where adding the IO cycle to a capable machine with a variety of programming models is very advantagious and even easier than trying to fit them all to ladder logic. The market leaders agree that there is need for this sort of mixed model but, they sort of turn it upside down and slave the BASIC,C or whatever coprocessors to the scanning engine.
The technology is certainly available to overcome this and the additional hardware resources needed are no longer prohibitively expensive. Compared to the selling price of equipment, the difference
between a deeply embedded class processor with resources and a processor capable of running a modular OS with resources is arguably justified when balanced with the greatly enhanced capability. Once you overcome that hurdle, the ease of programming and support for services difficult to provide with the old model should make it a no brainer. Part of the reason I am embarking on PCPLC Open Hardware project is to prove this concept. Actually it has been mostly proven by the majors themselves with the new class of panel PCs that also do some logic. Since they are approaching the same conclusion, I would hope that they could see the wisdom of going that last mile and standardizing on something similar in concept to the PCPLC rather than each reinventing the wheel. Imagine how many precious
R&D dollars that would save and the potential for addressing a new class of cost-sensitive networked solutions with no additional hardware required. A whole new market.


Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.