As the world begins to come out from under the oppressive cover of a nearly three-year epidemic, the false starts and side trips that have plagued our journey on the automation highway can finally make some headway again. Like the highly anticipated family vacation, the desire to hit the open road with our projects leaves us apprehensive and, perhaps, a little sleepless.
Feeling slightly retrospective, I find myself looking back on the past 33 months with a small bit of wonder. How the heck did we survive all this?
Also read: Ethernet vs. fieldbus
While the health concerns were paramount, one lesson that we learned is that, no matter what challenge we face, underneath it all we are human and we still require the basic necessities. As a food producer, our objective of producing good, quality products never wavered but the virtual snowballs tossed at us as we struggled to keep our eye on the target made for some interesting times.
These are the moments where we learn what we are made of. The stress to do what used to be just ordinary things can teach a lot about the character of the people we work beside every day. Some crack, but most dig in their heels and take on the extra weight with focus and determination.
For those of us who design, the journey we have been on seemed more like a ride through a neighborhood full of speed bumps than a lung-clearing sprint down an expressway. While we all learned how to reach into a bin full of components that may not have been of our choosing, the one feature that brought our designs to life was the common pathway that connects them all together. I am speaking, of course, of the network.
Automation networks have come a long way. In the early years of automation, stepping into the world of control design was like walking into a meeting of the League of Nations. Everyone had something important to say, but no one knew what the other person was saying.
Like the evolution of humans, the logical place to start is to group things together that have something in common. As the group gets bigger, the desire to do more becomes a natural next step. Eventually, without realizing it, we have a large group of components that can talk to each other, but we are still left with the problem that these larger groups can’t talk to each other.
This scenario, while painted with a broad brush by yours truly, represents the world we lived in back in the early 1980s. Manufacturers all had their own ways of talking—networking—and developed devices that broadened that box of goodies, but only for themselves. Automation companies were hoping that once you were hooked on their bag of goodies, you wouldn’t want to use any of the other guys’ stuff.
Like the automation components themselves, the industrial networks needed to go faster and further. Still thinking in the restrictive manner of a nation state, new network protocols were developed that talked to the same group of components but at faster speeds.
The new ones were faster than their parents, but they still were limited to communicating with their own neighbors. The communicating world back then used protocols such as serial communication, RS-485 standard, Remote I/O, Modbus, Profibus, CANbus, Factory Interface Network Service (FINS), Data Highway (DH), Data Highway Plus (DH+), because “plus” is better, of course, DeviceNet, ControlNet and an emerging protocol called Ethernet. What was missing, to give a nod to my favorite science-fiction genre, was the universal translator.
Over the years, manufacturers of automation components realized that making devices that only talked to your own network protocol severely limited the market in which to sell those devices. A few protocols rose to the top of the pile, based partly on the installed base of the components that talk with that protocol and partly because the technology behind the protocol advanced—got faster and easier to use—to the point where the other protocols were no longer practical.
The logical thing to do was to get together and work out a way to settle on one protocol with which all the various vendors would make products to communicate. As it turns out, much like the rest of humankind, not everyone could settle on only one winner in the protocol race, but it sure thinned out the field a lot.
One such protocol that has grabbed a large share of the marketplace is Ethernet/IP, the latest iteration of industrial Ethernet. Think of industrial Ethernet as the Ethernet used to connect your computer or laptop, but made more robust so that it can survive in a manufacturing environment.
Ethernet/IP literally means Ethernet/industrial protocol. It combines the common industrial protocol (CIP) with standard Ethernet. Both standards are supported by ODVA, an organization formerly known as the Open DeviceNet Vendors Association. Members of ODVA are independent vendors who supply devices for industrial automation applications.
Ethernet that is designed for an industrial environment has additional protocols to make it deterministic and enable real-time control. Deterministic, as applied to networking, means that the exact time to transmit and receive a message is known and predictable. If the time to send a command and get a responding message back is known, then real-time control can be achieved.
Before the ability to make Ethernet deterministic, specialty network protocols were needed for time-critical events, such as motion control. Dedicated motion networks such as Sercos were used for this purpose, but significant additional hardware and cost were involved since the programmable controller could not be counted on for precision motion and position control.
An important feature of Ethernet/IP is that it is media-independent. This has permitted a variety of wiring methods to be employed, based on an application. The four primary types of cables for Ethernet are coaxial, fiberoptic, unshielded and shielded twisted pair. The most common cable technology is twisted pair with unshielded or shielded, a decision based on whether the environment is noisy, needing shielded, or not. The most common method of termination of twisted pair is RJ45.
RJ45 is a modular connector in which four sets of twisted pairs are trapped between two modular pieces in such a fashion as to penetrate the insulation of the individual conductors and create a connection to exposed, flexible copper strips. The connector, when plugged into a matching receiver, creates a reliable connection to upstream and downstream devices. An RJ45 connection is not sealed, meaning there is risk of exposure to powder and liquid contamination of the connection.
An alternative to the RJ45 connector is a D-code or X-code connector in an M12 format. M12 means a 12-mm-round connector that provides IP67 and IP68 environment protection. These two categories both have dust- and water-proof properties, with IP68 being more robust than IP67.
Both connectors usually employ four or five conductors and are easily identifiable by the shape of the insert inside the M12 outer shell.
The D-code looks like a D—round with a flat side—and the X-code looks round with an X through the middle. Both connectors can also have additional features—small cutouts that match opposing pegs in the mating connection—that make it impossible to connect in an incorrect manner.
Unlike the RJ45 connection, the D- or X-code connector firmly mates the correct conductors and completely encloses the exposed connection so that outside contaminants can’t get into the connection points. Use of either of these two connection types varies by vendor and application and is a great way to make sure that a component isn’t plugged into the wrong communication cable in the field.
D- and X-code connectors are often used for bulkhead connections where field cables connect to an electrical enclosure. Once inside the enclosure, standard RJ45 connections are suitable to bring the connection from the bulkhead to an Ethernet switch or device.
Regardless of the media or method of connection, the acceptance by most vendors of the Ethernet/IP standard with the common industrial protocol makes connectivity easy to set up and use in a control system.
One thing to keep in mind when selecting a programmable controller for your control system is to make sure you know how many devices will be directly addressed through your design. Most programmable-logic-controller (PLC) or programmable-automation-controller (PAC) applications will have a hardware tree in the development software that creates automatic tag connections for your application to use.
Each device will occupy a node on your network, and each PLC/PAC has a limit on how many nodes can be addressed in such a manner. While the nodes on any Ethernet subnet are limited to 254, the PLC or PAC direct addressing will be much less.
Examples of dedicated nodes would be servo and variable-frequency drives, encoders, safety relays and other devices that use a software profile, sometimes called an add-on profile, to automatically format the exchange of data words into recognizable tag structures. Not included are any devices that solicit information but don’t create tags.
A good example of this is a human-machine interface (HMI) device. The device application will define where to read and write tags that are defined in the PLC/PAC without creating any tags of its own.
Think of Ethernet/IP as the universal translator that provides a common highway for your various components to talk to each other in a meaningful way.
