Google AdWords&Guerilla Marketing

Putting Sensors on Ethernet—
A Good Fit or a Bad Idea?

Ethernet is finding its way into machine control, even though it was never intended for embedded applications. The desire to use widely supported hardware and TCP/IP software means vendors are adding Ethernet ports to smart devices. Here’s a look at the issues that users and OEMs must consider when using Ethernet at the lowest level.

Perry S. Marshall, Perry S. Marshall & Associates

Few topics in automation are as hotly discussed as industrial Ethernet. As Ethernet cables work their way down from the office to cell-level machine control, to smart devices and data acquisition, connecting sensors with Ethernet has become a reality. Of course, anyone in industry who’s been paying attention knows that there’s a history of competing network standards—GPIB, Profibus, CAN, Modbus, Remote I/O, Sercos, Interbus, Genius I/O, and Foundation Fieldbus, just to name a few. In 1997–1998, some industry insiders began to propose that Ethernet and TCP/IP could be a viable alternative. Years ago, Ethernet hardware was expensive, but the inevitable forward march of consumer technology and the growing popularity of computer networking drove volumes up and prices down.

All network architectures represent some sort of compromise. And though Ethernet cannot realistically replace all of these other networks, it represents a clear rallying point for proponents of open systems. The Internet is the ultimate open network, and TCP/IP is the de facto protocol for the Internet. The confusion of multiple fieldbuses is partially eliminated by the common physical layer and software layers of Ethernet and TCP/IP.

Why Ethernet Isn’t a Natural Candidate for Sensor Applications
Ethernet began in the mid 1970s as a network for linking large computers, and the TCP/IP protocol was common to Unix and IBM mainframes. So Ethernet and TCP/IP evolved together. They’re ideally suited for transferring large amounts of data (1 KB and more), as opposed to small amounts, such as those gathered from sensors.

An Ethernet frame has a minimum length of 64 bytes, and a TCP/IP packet inside the data field of the Ethernet frame adds its own overhead (see Figure 1).

Figure 1. An Ethernet frame can be of varying length, depending on the length of the message. The TCP/IP packet itself is complex and fits entirely within the message frame.

It takes seven handshakes just to open a TCP/IP connection, transmit one piece\ of data between two devices, acknowledge successful receipt of the message, and close the connection. When moving small amounts of data, this represents significant inefficiencies. If you’re transmitting a single bit for a proximity switch or 2–4 bytes for an analog transmitter, the headers and handshakes consume a lot of overhead compared with the data itself.

Why Ethernet Is Moving into Sensors Anyway
Despite these disadvantages, embedded Ethernet hardware and software are readily available and dropping in price. So if you use Ethernet, the inefficiencies aren’t much of a concern anyway, especially if high speed is not paramount.

You won’t be seeing $20 proximity switches with Ethernet ports any time soon, but there are more sophisticated kinds of sensors that are a natural fit for Ethernet:

Vision systems and optical devices
Bar-code readers
Distance or velocity measurement devices
Devices with built-in DSP functions
Temperature controllers
I/O devices that aggregate multiple sensors together

Any sensor that delivers complex information and has a list of configuration parameters that must be uploaded or altered is a candidate for Ethernet connectivity.

For years, users have configured devices with manually manipulated text files, but this is out of vogue. Today, most people would opt to use an embedded Web server, which would let them put a device on a network, type in its IP address, and configure it on screen with their Web browser. That’s usually the case if you purchase a configurable (or “managed”) Ethernet switch, DSL, or cable router. A smart sensor with the same capability is far easier to use than a traditional sensor. And of course, it’s equally appealing to be able to access that device via your company intranet or the Internet.

Critics often cite determinism as a weakness of Ethernet, and this point does have some merit. With Ethernet, you can’t be sure how fast a piece of data will be transmitted through the network. However, if you use switches instead of hubs, you eliminate collisions and re-transmits and significantly improve the predictability of system performance. In applications that don’t require response times under 20 ms, determinism is not usually a problem. However, be aware that software drivers usually introduce much greater latencies than the network itself.

Hardware for legacy and industrial networks can be pricey, but Ethernet hardware is plentiful and often inexpensive. If your application is in an environment plagued by electrical noise, shock, vibration, or temperature extremes, then consumer-grade Ethernet gear won’t make it. The white paper Ten Issues to Consider Before Installing Industrial Ethernet details these and other factors. To request it, e-mail sensors@ccontrols.com.

Is Ethernet Cheap?
Just because it’s Ethernet doesn’t make it cheap, and “cheap” certainly is not sufficient justification for using a particular network. Although it’s inexpensive to add an Ethernet card to a PC, adding this capability to an embedded device is more complex. Often small microprocessors can’t handle the extra burden, and the software complexity is cost prohibitive.

The real question is, what do you gain by using Ethernet? How much is it worth to have remote diagnostics and configurability, and the ability to transmit far more information than would be practical with point-to-point wiring? How much is it worth to do your wiring in software instead of pulling a fistful of cables through conduits? How much is it worth to have access to every variable in the device instead of just a few?

Today, access to information is the name of the game. So regardless of the cost of using a network, your ability to access the information you want, when you want it, is the “real deal.”

SIDEBARS:

Application-Layer Protocols

Ethernet and TCP/IP alone don’t guarantee interoperability between devices; they ensure only that the data can get from point A to point B. It’s still necessary to understand the format of process data when it’s received.

In automation and process control, there are five major network contenders:
• Modbus/TCP is the Modbus protocol encapsulated in TCP/IP. It’s very simple and has definite limitations but at the moment is the most popular single format for data on industrial Ethernet.

• EtherNet/IP is the DeviceNet/ControlNet object model on TCP/IP. It’s more complex and supports more communication types. Products with EtherNet/IP are just starting to become available.

• Foundation Fieldbus HSE (High-Speed Ethernet) is the Foundation Fieldbus protocol on 100 Mb Ethernet, which is emerging as a major standard in the process control industry.

• Profinet is fundamentally different from such protocols as Modbus/TCP, in that it is not the Profibus protocol on Ethernet per se; rather, it is a sophisticated object-oriented architecture for making networks and devices transparently accessible as objects on a TCP/IP network, analogous to Microsoft Networking in the office.

• IDA (Interface for Distributed Automation) is similar in concept to Profinet, but it includes fieldbus-like features and is based on open Internet protocols instead of Microsoft’s COM and DCOM models.

Ethernet Topology and Terminology

Figure 2. Ethernet's star topology allows maximum bandwidth and minimum reflections by allowing only two nodes per segment. Repeaters (hubs and switches) isolate segments and clean up signals.

Star Topology. Industrial Ethernet is wired in a star topology, requiring either a repeating hub or switching hub in the center of the star (see Figure 2). So forget about wiring your conveyor system in a convenient bus topology. If you want industrial Ethernet, you must wire it in a star or distributed star topology. A distributed star requires a hub-to-hub connection.

Hubs. Links are established between a single Ethernet device and a port on a hub. Hubs usually have 4, 8, or 12 ports. Hubs can be cascaded with hub-to-hub connections.

Repeating hubs must conform to the requirements for IEEE.802.3 repeater units. These requirements include preamble regeneration, symmetry, and amplitude compensation. Repeaters must retime signals so that jitter introduced by transceivers and cabling doesn’t

Figure 3. A hub retransmits all messages to all devices indiscriminately. A switch directs traffic only to its intended destination, thereby reducing network congestion. Networks with switches have higher performance but are more difficult to troubleshoot.

accumulate over multiple segments. These devices detect runt packets and collisions and react by generating a jam signal (see Figure 3). They automatically partition jabbering ports to maintain network operability.

Switches. It’s possible to replace repeating hubs with switching hubs and achieve higher network performance. Unlike repeating hubs, which are physical-layer devices, the switching hub is actually a bridge that connects two data links. By doing so, collision domains terminate at each switch port. Therefore, adding a switch doubles the possible geographic limit of the network. Switches can be cascaded for an even larger network.

Switches are more complex than repeating hubs. Each twisted-pair port and attached device automatically negotiate the data rate of the port, be it 10 Mbps or 100 Mbps. The flow control mechanism is also negotiated. For full-duplex segments, the pause scheme is used. For half-duplex segments, the back pressure approach is used. The switch learns the port locations of Ethernet devices by reading in complete Ethernet frames and observing source addresses. The switch then creates and maintains a table of source addresses and corresponding port assignments. From that time on, traffic is restricted to only those ports involved in a transmission. This allows for improved throughput because simultaneous transmissions can be initiated on those ports without activity. Table values are aged to automatically accommodate changes to the field wiring.

Cable. You can use shielded twisted-pair (STP) or unshielded twisted-pair (UTP) cable, or multimode or single-mode fiber-optic cable. There are several categories of twisted-pair cable based on bandwidth and, therefore, performance. At the 10 Mbps data rate, there usually isn’t too much concern about cable quality. However, if plans are for eventual migration to 100 Mbps, then either Category 5 or 5e is recommended. In fact, if you are pulling new cable, use only one of these two cables. UTP is much more popular than STP.

For each fiber-optic link, a pair of fibers is required. Usually several fibers are pulled to provide spares. The most popular multimode fiber-optic cable is 62.5/125 mm dia.

Connectors. For twisted-pair cable, the RJ-45 remains the most popular connector, although it’s frequently criticized for its lack of robustness. In the IEEE 802.3 standard, the DB-9 connector, frequently found in industry, is specified for 150 ž STP installations. However, this connector might be confused with serial port connections on the same equipment. There has been a movement to use IP67-rated microconnectors for data rates as high as 100 Mbps. As a compromise, bulkhead-mounted boot-covered adapters exist to make RJ-45 connectors survive an IP67 environment.

(The material in this sidebar was excerpted from the white paper Ten Things To Consider Before Installing Industrial Ethernet © 2002 Contemporary Controls.)

"Originally appeared in Sensors Magazine"

Back

AdWords(TM) is a Trademark of Google Inc., Mountain View, California.
Perry S. Marshall & Associates is an independent consulting & publishing firm, and is not affiliated with Google.