Ethernet communication tips
Details of Ethernet in an industrial environment can be hard to find, and resources specific to industrial Ethernet hard to come by. Users often overlook the possibility of using Ethernet to manage application response time for end devices. Ethernet switches and cabling can be easily installed by a user, interconnecting dozens or hundreds of devices, and eliminating many legacy fieldbus restrictions such as node counts and distances. Here are tips and specifics that can be useful.
The details of Ethernet in an industrial environment can be hard to find, and resources specific to industrial Ethernet hard to come by. So here are some tips and specifics that can be useful.
Users often overlook the possibility of using Ethernet to manage application response time for end devices. Ethernet switches and cabling can be easily installed by a user, interconnecting dozens or hundreds of devices, and eliminating many legacy fieldbus restrictions such as node counts and distances.
When estimating timing for Ethernet I/O, remember than an application must read an input, solve the input in logic, and respond by writing an output, which means communications between the I/O module and the PLC CPU is occurring twice.
Communications programming for programmable logic controller (PLC) Ethernet applications can be done by simply entering the desired devices and register counts into a table. But understanding the proper timing of communication settings is important, and will result in a more reliable, error-free operation.
To estimate the timing, consider that an application must read an input, solve the input in logic, and respond by writing an output. This requires two network communication cycles between the master and end device: one to read, and another to write (see illustration). In between, there is the Ethernet interface stack processing, logic solve for central processing units (CPUs), and communications servicing in the devices via backplane or bus.
Putting this knowledge into a real-world context, consider what is meant by a “fast response time” for an Ethernet I/O module, which is often quoted as a few milliseconds. Realistically, the communications cycle to the I/O module must occur twice, along with two CPU scans for the master PLC.
The “fast response” quoted is to send a message to the module and for the module to react to that message. As you can see, that does not accurately reflect the real-world operation. The cycle or repetition rate of communications should be a multiple of 2.5 to 3 times the master PLC scan time. This will allow problem-free communications, because then PLC masters will have sufficient time to solve logic and process communications, and the end devices will have responded to changes in input or output status.
While the robustness of the Ethernet infrastructure handles substantial traffic loads with ease, end devices may be overwhelmed by multiple masters. Simple devices with limited processing power can take a few milliseconds to respond. Even robust PLCs that service communications at the end of a CPU scan will buffer requests until the end of the scan. Issues will not give responses until the CPU scan is complete.
One concern remedied
One of the biggest concerns in the beginning stages of industrial use Ethernet was non-deterministic performance due to collisions, which occur by design, in half duplex Ethernet networks. As node density increased, performance grew increasingly worse.
With the advent of full duplex switched Ethernet in the mid 1990s, backbone collisions were virtually eliminated and performance improved. Most newer end devices now support full duplex operation. This has led to a substantial increase in system performance and greater response time consistency.
An inherited benefit of such consistency is the ability to expand the node count of industrial Ethernet networks. A switched Ethernet with full duplex operation can now approach determinism with repeatable transmission times from one end device to another. While most networks regarded as deterministic are token-based, having a predictable and repeatable transmission time between devices is sufficient—and essential for industrial uses.
Depending on the buffering and the forwarding delays of each switch in the path, the time to transmit a message from one end point to another while passing through switches varies slightly. However, switch forwarding delay is generally under 50 microseconds per switch. Buffer congestion can be managed using IEEE 802.1p Quality of Service prioritization. Therefore, it is likely that the actual transmission time from one device to another will consistently be within a millisecond, which is satisfactory for most applications.
New challenges on the horizon
Ethernet and TCP/IP provide a rich set of features for global communications, monitoring, data exchange, and Web accessibility. But assembling new-generation Ethernet performance, features, and services into a comprehensive enterprise solution is a challenge end users continue to face.
Another ongoing challenge exists in putting these technologies to work in harmony. As users try to determine how each technology fits within the overall enterprise architecture, system solutions that improve efficiency remain top of mind.
With legacy systems, communication and data interchange are confined to the manufacturing site. Now, Ethernet and TCP/IP make the same data available globally and in real time.
Harnessing the power of these technologies allows business to improve the entire operation, from the flow of raw materials to the distribution of finished product.
At www.controleng.com , search Industrial Ethernet for more resources
Michael B. Roche is principal network application engineer for connectivity products in the Automation business unit of Schneider Electric End User Solutions. To find out more about Schneider Electric’s Telemecanique brand of Ethernet hardware and industrial networking services, visit
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.