Ethernet/IP and Modbus/TCP Network

Old No. 7

Member
Join Date
Jun 2010
Location
Ohio
Posts
173
Working on a project with a bunch of communications and wanted to make sure we're not getting ourselves into trouble.

We're going to have a Controllogix PLC with about 25 HMI's, VFD's, and Point I/O all in a device level ring. These are spread out in a few different control panels but relatively close to each other (150 feet max).

In addition we have another 50 Modbus/TCP devices (servers) that we are collecting data from with Prosoft cards in the PLC rack.

My understanding is that in order to break into the DLR, we should use a 1783-ETAP and then you can use ethernet switches on the other side of the ETAP for devices that don't have DLR network capability.

So my questions are:
Should the Modbus/TCP traffic be isolated from the DLR Ethernet/IP traffic?
If it can be run together, what is the best way to connect the Prosoft modules into the ring? Add an ETAP for each one?
Can we use unmanaged switches to connect all the Modbus/TCP devices together and then a single ETAP to get them into the ring?
Is this whole setup asking for trouble? This is a lot more ethernet devices than we've ever done before.
 
EtherNet/IP and Modbus/TCP traffic can happily co-exist on most Ethernet networks. The DLR ring is independent of protocol and will route both kinds of data around the ring just fine.

When I build DLR networks, I generally put an unmanaged switch (often N-Tron 100 or 500 series) and a 1783-ETAP into each cabinet or workcell that has non-DLR stuff. My HMIs and engineering workstations and single-port devices and non-DLR devices all connect to the ring via the ETAP.

A handful of considerations:

1. Research and document the default IP addresses of any devices that have a default address or a physical setting for the last octet. Don't use anything's default address for a real device if you can avoid it.

2. Plan for remote access and segregation from the enterprise network. Connecting your network directly to the Internet, or even to your corporate network, is a recipe for mischief.

3. If you have an HMI or engineering workstation or router that's going to be your point of entry, be sure that its LAN address is entered as the "Default Gateway" for the other devices.

4. Collect notes on configuration of all your networked devices in an appendix to the user manual or maintenance guide. It's helpful down the road to have a set of credentials and know the basic interface method (browser, RSLinx, special utility, TELNET ?) that is required to set up a replacement device.

5. If you do use A-B devices with the last octet set by dials or selectors (PowerFlex and POINT I/O come to mind), they will have a pure LAN address of 192.168.1.XXX, subnet mask 255.255.255.0, and no default gateway. That means you generally need a VPN to get into the network from outside, not just a router, because devices with no default gateway configured won't communicate to anything with a non-LAN address.
 
regardless of the ethernet protocol (TCP, Modbus/TCP, etc), when you build your logical topology with switches be careful not to form a ring. if you build a ring or loop with switches you'll have to manage your switches with spanning tree protocol. if you build it in a star pattern you can avoid having to configure spanning tree.
 
regardless of the ethernet protocol (TCP, Modbus/TCP, etc), when you build your logical topology with switches be careful not to form a ring. if you build a ring or loop with switches you'll have to manage your switches with spanning tree protocol. if you build it in a star pattern you can avoid having to configure spanning tree.

He's using DLR, which is a Ring protocol designed for redundancy with bumpless failover. If one of the ring switches goes down, no data on the network is lost.

Spanning tree (and Rapid Spanning Tree) both have reconfiguration times that would cause loss of data on the network.

A star topology gives no redundancy at all. In most cases, Star is the way to go, but using a ring protocol like DLR (or a number of others) often makes sense.
 
He's using DLR, which is a Ring protocol designed for redundancy with bumpless failover. If one of the ring switches goes down, no data on the network is lost.

Spanning tree (and Rapid Spanning Tree) both have reconfiguration times that would cause loss of data on the network.

A star topology gives no redundancy at all. In most cases, Star is the way to go, but using a ring protocol like DLR (or a number of others) often makes sense.

Yes, there is a ring for all of the Ethernet/IP devices and then a couple stars with ETAP's connecting them to the ring.
 
EtherNet/IP and Modbus/TCP traffic can happily co-exist on most Ethernet networks. The DLR ring is independent of protocol and will route both kinds of data around the ring just fine.

When I build DLR networks, I generally put an unmanaged switch (often N-Tron 100 or 500 series) and a 1783-ETAP into each cabinet or workcell that has non-DLR stuff. My HMIs and engineering workstations and single-port devices and non-DLR devices all connect to the ring via the ETAP.

A handful of considerations:

1. Research and document the default IP addresses of any devices that have a default address or a physical setting for the last octet. Don't use anything's default address for a real device if you can avoid it.

2. Plan for remote access and segregation from the enterprise network. Connecting your network directly to the Internet, or even to your corporate network, is a recipe for mischief.

3. If you have an HMI or engineering workstation or router that's going to be your point of entry, be sure that its LAN address is entered as the "Default Gateway" for the other devices.

4. Collect notes on configuration of all your networked devices in an appendix to the user manual or maintenance guide. It's helpful down the road to have a set of credentials and know the basic interface method (browser, RSLinx, special utility, TELNET ?) that is required to set up a replacement device.

5. If you do use A-B devices with the last octet set by dials or selectors (PowerFlex and POINT I/O come to mind), they will have a pure LAN address of 192.168.1.XXX, subnet mask 255.255.255.0, and no default gateway. That means you generally need a VPN to get into the network from outside, not just a router, because devices with no default gateway configured won't communicate to anything with a non-LAN address.

Thanks Ken.

So 50 devices' worth of Modbus/TCP traffic on the DLR wouldn't concern you?

All of the IP addresses will ultimately be defined by the customer, but I doubt they will be on 192.168.x.x. We won't have a permanent PC on the system anywhere, just laptops during startup. Can/should the default gateways be set to something in this case?
 
I wouldn't be that worried with 50 devices talking Modbus TCP, unless you are are using all 5000 INTs in all 50 cards with updates to the PLC every second. I would think you will need to watch your connections and PLC resources more closely than anything else.
 
50 typical devices doing Modbus/TCP will barely make a modern 100 MB/sec switched Ethernet network break a sweat. Because it's ordinary TCP data, the switches will confine it to just the endpoint ports and the Prosoft module ports.

EtherNet/IP is typically run as unicast UDP data, which the switches also handle effectively. Only if you un-tick the "Use Unicast Connection" box on each connection does it run as Multicast and get propagated to all ports or constrained by IGMP Snooping.

I always plan to have a remote access router or gateway or VPN appliance attached to the network, even if one hasn't been ordered by the customer. I even plan for it with customers who adamantly ban remote access to their systems, both because they often change their minds and so that my networks are consistent.

If you definitely don't plan to ever have non-LAN devices, leave the subnet mask blank.

Otherwise I tend to set it up for the 1st address on the automation LAN subnet, like 192.168.1.1.
 
Definitely agree with the others. Unless you're transmitting some crazy amount of data (or need to do it crazy fast), Ethernet is plenty for whatever you want to do with a PLC and IO.

EtherNet/IP is typically run as unicast UDP data, which the switches also handle effectively. Only if you un-tick the "Use Unicast Connection" box on each connection does it run as Multicast and get propagated to all ports or constrained by IGMP Snooping.

Slightly off topic, but it's been a while since I've dealt with the big picture in EIP system. Has there been good third party support for unicast? How often do you see/what percent of devices are still multicast only?
 
Definitely agree with the others. Unless you're transmitting some crazy amount of data (or need to do it crazy fast), Ethernet is plenty for whatever you want to do with a PLC and IO.



Slightly off topic, but it's been a while since I've dealt with the big picture in EIP system. Has there been good third party support for unicast? How often do you see/what percent of devices are still multicast only?

I don't use a huge variety of 3rd party devices but I don't remember the last time I came across a device that didn't use unicast
 
maybe this is no longer a problem with modern equipment - I would sure hope so - but some older Modbus TCP devices, even when purchased today, are 10hdx and don't play nicely with auto sense of some switches. Chatty little buggers.
 

Similar Topics

Does anyone have any recommendations for Electronic Circuit Breakers with 0V Terminals built-in and Fieldbus (IO-LINK, MODBUS TCP, EtherNet/IP?)...
Replies
2
Views
167
Hello, Sorry, my knowledge of communication protocol is limited, so thank you in advance for your answer. My question; I want to get 5 values...
Replies
2
Views
838
Hi All, Trying to help a client who has a project that was started with Schneider STB remote I/O, but they are still waiting on the STBNIP2212...
Replies
11
Views
1,842
Hello all, I was wondering if you clever people could help me, please. In the past I have used a standalone L33ER CompactLogix PLC with the...
Replies
5
Views
1,463
Hi all IÂ’m working on a problem in which I have to read sensor data from a data acquisition module in the field that only communicates using...
Replies
2
Views
1,703
Back
Top Bottom