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).
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.
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.”