The Wide, Wide World of Switching

There’s one thing that most of us EtherNet/IP, Modbus TCP or PROFINET IO vendors will never talk about: architecting your EtherNet/IP network. We’ll give you all the reasons to use EtherNet/IP. We’ll tell you the reasons to implement EtherNet/IP using source code. We’ll tell you why you might want a hardware solution. Why you shouldn’t use a gateway. And we’ll go on and on about the technology: messaging; connections; PLC configuration and more.

But we won’t discuss how you should architect an EtherNet/IP application. Dare I say that it’s probably because I (and most likely we) really don’t know much at all about using EtherNet/IP. I have no problem telling you to use it, but don’t put me on the factory floor and say “build an EtherNet/IP system.” That’s beyond my scope of competencies if I am honest with you.

Well, I’ve done some studying on EtherNet/IP application architecture, and I’ve learned that it’s more than just plugging a PLC and some EtherNet/IP devices into a switch. That works fine for small systems, but we usually don’t have applications small enough so that the PLC and all its devices can exist on the same switch. Once you have more devices than ports, you’re faced with a whole host of architecture issues.

One way to solve the port problem is to use STACKABLE SWITCHES. Stackable switches are switches that are physically arranged in a stack. There is a communication channel between them that effectively makes the 3, 4 or 5 switches into one switch (3 x 16-port switches = a 48 port switch). There is one IP address for the switch, and it looks to the outside world as if you have a very large switch. Having one IP address is key because there can be bandwidth and troubleshooting issues with some of the other solutions. The limitation to stackable switches is that you must run all your devices back to the same physical location. That’s often not possible in an environment with devices distributed all over.

Another mechanism is CASCADED SWITCHES. Cascading refers to plugging multiple switches into the primary switch. Three 16 port switches provide 44 ports. Two ports are used on the primary to connect switches #2 and #3, with one port used on #2 and #3 to connect to the primary. In this architecture, one port on the primary is dedicated as the uplink port to the network infrastructure. All traffic between the PLC and devices on #2 and #3 must flow through the primary. All switch traffic itself must flow through that same uplink. Bandwidth problems must be carefully considered in all these scenarios.

Another mechanism that is often used is DAISY CHAINED SWITCHING. Instead of connecting switch numbers 3, 4 and so on to the primary, you connect switch 2 to the primary, switch 3 to switch 2, switch 4 to switch 3 and so on. You do get an additional port in this scenario, but you can destroy the bandwidth of switch 2 since it has to pass all the PLC traffic from the devices down the line to the PLC.

Now some people have implemented the worst of all worlds: mixing cascading and daisy-chaining on the same system. There really is no worse way to architect your EtherNet/IP, Modbus TCP or PROFINET IO system. You not only create bandwidth issues, but you also create a troubleshooting nightmare when you are trying to analyze traffic. I may not be an expert on network system design, but I know enough to avoid that architecture.

Another architecture to consider is linear segmenting. With linear segments, you use EtherNet/IP devices with embedded switches, and traffic routes from the input port of the switch through the device and out the switches to the output side to the next device. You can daisy chain as many devices as you want in this fashion. But again, you need to be cognizant of the bandwidth issues with long linear segments, especially on daisy-chained switches as all that traffic has to flow through the same path to the PLC.

The bandwidth issues become important when you start using a network monitoring tool located outside the network segment. All the traffic from devices, the PLC and the switches must be routed to the uplink port on the primary switch. Even though PLC traffic generally accounts for less than 10% of bandwidth, you’re taking a risk by using daisy-chaining or cascading and daisy-chaining.