Ethernet’s in Control

Already facing several choices when choosing a fieldbus network, engineers now have another—Ethernet. Yes, that's the same Ethernet IT uses to connect PCs to the enterprise and ultimately the Internet. Well, it is almost the same.In the face of all the other fieldbuses with vendor groups, big company support, technical committees, and compliance testing, why is anyone looking at Eth...

By Gary A. Mintchell, CONTROL ENGINEERING May 1, 2000
  • Networks and communication

  • Machine control

  • I/O systems

  • PC-based control

  • Device-level networks

Protocols unveiled
Terminator I/O
Open network controller provides integrated networking

Already facing several choices when choosing a fieldbus network, engineers now have another-Ethernet. Yes, that’s the same Ethernet IT uses to connect PCs to the enterprise and ultimately the Internet. Well, it is almost the same.

In the face of all the other fieldbuses with vendor groups, big company support, technical committees, and compliance testing, why is anyone looking at Ethernet? Mike Justice, Synergetic (Downers Grove, Ill.) president, says that customers are asking for it. They think that Ethernet will be faster, easier, and cheaper. They can leverage current infrastructure and training. He warns that these reasons can be true, but not for all applications.

Dave Hietanen, GE Fanuc Automation (Charlottesville, Va.) communication products product manager, notes, ‘The primary drivers for using Ethernet as a fieldbus are that it’s a standard, it’s readily available, it’s easy to set up, and the parts are relatively inexpensive. Since Ethernet is the most popular and widely used networking technology, many people are knowledgeable about how to implement and maintain it.’

Dick Caro is vice president at ARC Advisory Group (Dedham, Mass.) and a long timeproponent of Ethernet as a fieldbus. ‘Foxboro I/A Nodebus has used 10base5 Ethernet for years,’ he says. ‘The new I/A Fieldbus uses 10baseT. As for connectors, RJ-45 is OK in the control room or switchgear center-or even inside an equipment rack. In high vibration areas, General Motors has shown that it gives intermittent connection. Woodhead Connectivity has built an RJ-45 inside an IP67 sealed bulkhead connector. I think Hirschmann will propose a pin and socket connector similar to the one used for Profibus which provides both vibration and sealing.’

Ethernet can be deterministic

A major criticism of Ethernet for control is its supposed lack of determinism. The basic TCP version is based on probability theory, that is, the probability of collisions among packets of data on the wire can be calculated. Given certain loading considerations, a design can predict a ‘good probability’ of the packet reaching its destination in good shape.

Addressing this issue, Mr. Caro states, ’10/100baseT full duplex switched Ethernet is deterministic. Use of an active switch eliminates all collisions and the statistical setback that makes collision domain Ethernet nondeterministic. Switches do not even cost much these days.’

One of the problems encountered when discussing Ethernet is lumping various terms together under a single name. Ethernet really describes a physical medium and data linking. (See sidebar ‘Protocols unveiled.’) The issue goes beyond Ethernet to Internet Protocols. The ‘other’ fieldbus organizations are proposing putting their protocols on IP and Ethernet so that well known and highly developed IT networking technology can be the industrial networking architecture.

Protocols vary

Mr. Caro adds, ‘TCP/IP is the plain vanilla protocol that is easiest for the fieldbus groups to use, but it has many known deficiencies since it was designed for the public highly routed Internet. UDP is a simpler protocol that is much harder to use, but provides ways to improve performance on private networks. Modbus TCP has been public for almost two years and is the best example of taking a private protocol and mapping it to TCP/IP. Foundation Fieldbus HSE (high- speed Ethernet) is the best example of mapping to UDP for efficiency.

It is Type 5 of the new IEC 61158 Fieldbus ‘standard.’ This is the basis of publisher/subscriber protocol.’

Protocols are perhaps the most confusing part of understanding Ethernet for I/O device communications. Companies’ marketing strategies bring on part of the confusion. In a rush to point out benefits of its strategy, a company may lead potential protocol users and automation designers to believe that the entire architecture is in a state of chaos. Actually, some protocols are ‘open,’ while others are ‘proprietary.’ There is almost always a way to extract information from ‘proprietary’ systems to ‘open’ ones.

One important thing to remember is pointed out by Paul Ruland, PLC product manager for (Cumming, Ga.). ‘One of the benefits of Ethernet,’ he says, ‘is that you can run many transport protocols over the same wire. There really isn’t any reason to limit the use of a protocol.’

Many protocols coexist

Martin Wojcik, National Instruments (Austin, Tex.) FieldPoint product manager, says, ‘The Ethernet-based FieldPoint system can coexist with the TCP/IP system that is already present. We do recommend a dedicated Ethernet subnet in order to address the issues of reliability and determinism.’

National Instruments industrial hardware engineering manager, Garritt Foote, stresses, ‘TCP/IP is often used in place of IP which includes TCP and UDP. UDP and other messaging methods may be more appropriate for a particular application. The real advantage of using IP is that network administrators already have knowledge and a range of tools available to set up, maintain, and diagnose Ethernet networks based on IP. For example, an I/O network based on IP may be connected to a corporate IP network simply by using an IP router or gateway allowing data access across networks while maintaining a level of isolation.’

Why would it be advantageous to use a protocol based upon UDP rather than the ‘plain vanilla’ TCP? Consider this comment from Sixnet (Clifton Park, N.Y.) president, Steve Schoenberg: ‘Among reasons to maintain a proprietary protocol would be that Modbus uses number addressing while tag names allow easy communication with HMI software. The beauty is, you don’t have to choose. Different protocols run over Ethernet at the same time. Ethernet gives people choices.’

Robert Oglesby, president of Host Engineering (Johnson City, Tenn.) developer of the WinPLC for, says its version of UDP, which is registered, allows a search of every piece of hardware on the network with the protocol in its firmware. Functions like autodetect and autodiscovery are enabled. Control software can use this to show the programmer all the hardware in the system, enhancing configuration accuracy. Further, in one scan of the controller an output packet is sent for all I/O points with request for input status as the reply. Thus one scan can take the place of the usual four scans increasing speed.

Recently, the Open DeviceNet Vendors Association (ODVA, Coral Springs, Fla., ) announced a DeviceNet over Ethernet initiative. Control and Information Protocol (CIP), originally developed for ControlNet, is being adapted for use with DeviceNet and labeled ‘EtherNet/IP.’ A caveat is that the ‘IP’ in this case stands for ‘industrial protocol.’ The protocol allows peer-to-peer and I/O messaging on Ethernet TCP/IP with DeviceNet or ControlNet devices or eventually with devices embedded with CIP in their networking stack.

Encapsulating DeviceNet

Andreas Somogyi, Rockwell Automation (Milwaukee, Wis.) Ethernet product manager, highlights an important part of this protocol-encapsulation. ‘Encapsulation allows a data packet to be embedded within CIP and sent over Ethernet TCP/IP. With future development, this packet could be sent over other networks, as well. This would be a powerful communication device.’

ODVA is offering seminars providing in-depth technical information to help developers bring Ethernet I/O products to market.

Microprocessors are everywhere. They can be found in toasters, automobiles, and an ever-increasing number of factory devices. Tom Edwards, senior technical advisor at Opto 22 (Temecula, Calif.) suggests, ‘When choosing Ethernet I/O for your application, investigate local processing options and how they can improve overall system performance, reliability, and ease of use. With greater processing power, web servers can be installed on I/O systems revolutionizing access to these systems. With a browser, you can load a page to configure I/O points, test points, configure event/reactions and SNMP traps, set up report-by-exception, etc.

‘Local intelligence at the I/O level can relieve a central processor from tedious and time-consuming tasks like raw data conversion to engineering units. In addition, performance of a distributed Ethernet I/O system tends to be independent of overall system size because each I/O unit contains a processor.’

Industrial hardware

Horst Kohlbert, Siemens Energy & Automation (Alpharetta, Ga.) network product manager, addresses the crucial cabling issue. ‘Standard Cat5 [category 5, unshielded twisted pair, 10baseT] is good for a large number of applications, but when it comes to really nasty environments with floating grounds and so on, look for industrial cables. It’s the same story for connectors. RJ-45 is good for the majority of applications within a cabinet, but when we leave the cabinet, we usually use 9-pin D-shell connectors.

‘What I think we will see next,’ he continues, ‘are field devices with embedded Ethernet chips. Embedded Internet will become more of a reality. Direct connectivity to the Internet really ignited things; it’s the biggest benefit of the whole ‘Ethernet everywhere’ idea.’ ( Control Engineering , June 1999, cover story.)

Staffon Dahlstrom, vice president at HMS (Chicago, Ill. and Halmstad, Sweden), reports, ‘We use the RJ-45 connector, but we also have 9-pin D-shell as an option. This connector is already standard for Profibus and ModbusPlus and widely accepted as an industrial connector.’

John McGilvreay, Hirschmann (Pine Brook, N.J.) automation network solutions group, says, ‘The key to implementing Ethernet I/O architecture is switching technology. Within each control domain (comprising a controller, one or more Ethernet switches, and connected devices), controllers communicate with their attached devices through a switch that routes each TCP/IP packet through the appropriate port to the correct destination. For real-time applications, it’s best for each device to have a dedicated full-duplex port. Depending upon the application, either wire or fiber can be used to connect the controller and devices.’

Another useful hardware device is an interface to connect serial communications to Ethernet. Mark Fondl, vice president of Lantronix (Irvine, Calif.), describes a device ‘which can connect not only new devices but also any device that has a serial port. We are active in a number of fieldbus to Ethernet initiatives.’

Ethernet use growing

Is using Ethernet on the factory floor a theory with a bunch of crazy evangelists loudly crying in the wilderness? Hardly. Several companies have offered Ethernet for I/O module communication for two to three years. All report growing acceptance and sales of Ethernet products.

Host Engineering’s Mr. Oglesby responds, ‘I haven’t had a single customer complaint since we started shipping Ethernet I/O. Customer acceptance has been great.’

Opto 22 has offered Ethernet since the last quarter of 1998 and keeps adding refinements, like wireless access and SNMP for network management.

National Instruments has Ethernet communications to its FieldPoint I/O. Sixnet also offers Ethernet I/O modules. Schneider Electric (North Andover, Mass.) offers Ethernet connectivity to its Momentum I/O product.

Ethernet I/O connectivity continues to attract new products and players. Last year, Optimation (Huntsville, Ala.), a new company, announced Ethernet I/O modules. and Omron Electronics (Schaumburg, Ill.) have new product announcements in this article. GE Fanuc Automation announced at National Manufacturing Week that all of its automation devices will support Ethernet connectivity. Zoneworx (Temecula, Calif.) has introduced its first suite of products billed as the infrastructure enabling legacy devices access to Ethernet TCP/IP.

Steve Ewankowich, global account manager, applied materials for Schneider Electric, reports that ModbusTCP over Ethernet TCP/IP has achieved status as a standard in the semiconductor industry-SEMI E54.9-2000, Specification for Sensor/Actuator Network Communication for Modbus/TCP over TCP/IP).

Perhaps a glimpse of the future can be found in JetWeb by Jetter AG (Ludwigsburg, Germany, and Broadview Heights, O.). This product distributes control over Ethernet and promotes ‘the network is the controller.’ Certainly Ethernet can empower a vision of distributed control and universal information access for those who wish to bring it into reality.

Protocols unveiled

‘Ethernet TCP/IP’ has become a single noun in many suppliers’ vocabularies. Actually, there are many concepts behind this phrase that often lead to the famous FUD (fear, uncertainty, and doubt) Factor among engineers considering the best control and information network structures.

The ‘Ethernet’ part really refers to the physical media and some firmware of the network. The typical Ethernet network consists of unshielded twisted-pair (UTP) cable with an RJ-45 spring-tension, plastic connector at each end. Networked devices contain mating receptacles. Fiber-optic medium is now available for applications where electrical noise or distance may be problems. Connectors present a problem in many industrial applications where vibration and/or fluids are present. Several manufacturers are currently working on industrial Ethernet connections.

IP stands for Internet Protocol. Without this, there would be no Internet. IP, among other things, contains addressing so that one host can find another on the network. It is important to keep in mind that IP runs over anything. Not only does it run over Ethernet, IP can be used with IEEE 1394 (also called ‘Firewire’), Asynchronous Transfer Mode (ATM), and other media. Host applications generally access the Internetwork program through a transport program, Transport Control Protocol (TCP) or the User Datagram Protocol (UDP).

The IP suite also comprises ‘transport control’ protocols (TCP, UDP) and standard ‘applications’ such as ‘File Transfer Protocol’ (FTP) or ‘Simple Mail Transfer Protocol’ (SMTP). IP provides a best effort service: most datagrams make their way to their destination, but there is no guarantee that all will. Local congestion may cause the discarding of queued packets; transmission errors may cause their loss. The nature of the datagram service may also result in ‘disordered delivery’-as packets are routed independently, they may be spread over parallel routes. If a datagram posted shortly after another takes a different and slightly shorter or slightly less loaded path, it will arrive first. In very rare cases of failure, the network may even duplicate a datagram and deliver several copies of it to the final destination.

OSI and TCP/IP models represent layers of a network system from
physical media to firmware and software communication protocols. Note
Ethernet is the physical and data link layer.


TCP was designed to hide these errors to the applications. TCP builds a reliable end-to-end ‘connection’ on top of the datagram service. Each of the two communicating application programs can post a data stream over this ‘reliable pipe.’

UDP is an alternative to TCP for applications that prefer to use the datagram service directly. UDP allows applications to post packets to UDP ports identified by an IP address and a 16-bit port number. These applications will have to provide their own mechanisms for error correction and congestion control.

Generally, three reasons exist that make certain applications prefer UDP. Some client-server applications, like DNS (domain network server), consist of very simple exchanges: one query followed by one reply. Managing connections would be a waste, since the connection would have to be torn down immediately after a single packet exchange. Other applications are designed to run with extremely few resources. Programming a simple loop of ‘sending a request,’ or ‘await a response,’ requires less code than a full-scale file transfer over TCP. Other applications want to have complete control of their operation to make management decisions in case of transmission errors, rather than let TCP retransmit the same data again and again.

Applications reside on top of these transport protocols sifting though the transport information to get to the data inside. These include control and human-machine interface applications and communications like OPC.

Source for IP, TCP, and UDP information: Christian Huitema, Routing in the Internet, 2nd Edition, Prentice Hall PTR, Upper Saddle River, N.J.,

Terminator I/O

Terminator I/O from
combines functions of terminal blocks and I/O
modules for distributed I/O systems.

Terminator I/O from Automation combines features of terminal blocks and I/O modules into integrated modules. Terminal block features include triple-stack, three-wire device capability,integrated bused power and common terminals, and fused outputs. Network interface modules are available for Ethernet 10baseT and 100baseT, Profibus DP, DeviceNet, Modbus RTU, and Koyo Remote I/O. Discrete I/O modules are available in 8- and 16-point ac, dc, and relay with dc modules jumper configurable for sink/source. Analog modules are available in 8- and 16-channel models supporting 4-20 mA as well as unipolar and bipolar voltages.

Open network controller provides integrated networking

Omron’s Open Network Controller is both a
gateway between networks and a
controller in a distributed control system.

Omron’s Open Network Controller integrates industrial automation networks into ERP/MES and SCADA systems, enables web monitoring of control information, and can act as primary controller. Combining Omron’s middleware called FINS Gateway and QNX real-time operating system, the product reduces time and cost to establish and maintain communications between various devices in DeviceNet, serial, or Ethernet industrial automation networks. It can also be a controller by installing an Omron Sysmac board PLC into the available 1/2-slot ISA connector, using a third-party soft logic controller, or writing C or C++ applications to run on QNX.


What do you think about using Ethernet for control?