Contrologix Gigabit ethernet module

With the release of the 5580 processor with embedded 1Gb Ethernet port, how long before AB releases a communication module with gigabit capability. Anyone heard anything on the rumor mill? I have been upgrading my network to gigabit capacity (Cat6 cable, gigabit switches, faster PC NICs, etc..), and this would be one more upgrade.

I know many of my devices are only capable of 100Mb, but I would like to reduce any possible places of bottlenecks as I can.

Before reducing bottlenecks, have you actually found that one exists?
I rarely see more than 5% utilization, even on heavily loaded IO/Drives networks. Although GB Ethernet is reliable, it isn't as reliable or fault tolerant as current 100MB solutions.

Machine networks do not (well, should not) be transferring that much data anyway.

No issues as of right now, just planning things out for the future. My biggest issue is with my optimization PCs, and getting data to and from them at fastest possible rate, allowing them more time to come up with a solution. The network here has been pieced together over the years (since before I took over the lead role) and I am trying to streamline it to make it more reliable.

I don't expect a Gb comm module to change anything on 99% of devices, but perhaps in the future as more devices require more speed it will help then. I just want to be prepared when that day comes, hence wondering about the faster module. Obviously AB thinks more speed is going to be needed, and that is why they put Gb port on the new processor.

Mark Snodgrass said:

Obviously AB thinks more speed is going to be needed, and that is why they put Gb port on the new processor.

Click to expand...

Personally, I think they put it there because customers asked for it for the same reason you did: faster is better, right?

To me, as long as the network infrastructure you put in place supports Gb ethernet (switches & cables), then whether the end devices do or don't doesn't drag down anything else. Your optimization PCs can chat away at 1Gb over the network, and the automation can do its thing at 100Mb.

IO control networks probably won't ever need 1Gb, unless we really re-invent what we think of when we say IO control. At least with the amount of data I see per device, if we had so much IO that we were really using more than 100Mb of bandwidth, we'd start running into problems with broadcasts from all those devices taking the majority of the bandwidth. IT guys would shoot us for having networks that big.

Where 1Gb comes into play, to me, is for the PLC communicating outside the local cell. That could be your optimization PCs, or a SCADA system, or maybe sharing data to another controller. Has AB posted any statements regarding actual performance sending data out of the part? I'd be curious if the internals of the PLC could pump out data fast enough.

mk42 said:

Personally, I think they put it there because customers asked for it for the same reason you did: faster is better, right?

Click to expand...

The specific use case that I heard them talk about was for very complex motion camming on a large number of Servodrives. This allowed them to reduce the course update rate and hence have more points on the cam and make the cam more rounded and truer to the cam design.

That at least was the argument that they told us for having the 5580. In normal situations, when supper precise camming is not necessary the GB port is not necessary.

However If I was buying a new Control Logix PLC I would probably buy the 5580 since the price of it compared to a similar size 5570 plus a network card is almost the same. Just a shame they didn't make it a dual port device.

mk42 said:

Where 1Gb comes into play, to me, is for the PLC communicating outside the local cell. That could be your optimization PCs, or a SCADA system, or maybe sharing data to another controller. Has AB posted any statements regarding actual performance sending data out of the part? I'd be curious if the internals of the PLC could pump out data fast enough.

Click to expand...

That is exactly where my biggest concerns are. We actually send data from our PLCs, as well as our optimization PCs to a SCADA system (2300 miles away). It would be helpful if those connections are faster, as well as the PLC to PC and PLC to PLC connections.

Like you, I don't know if the processor would be able to keep up with a faster Ethernet. But, I would prefer it being the limiting component.

The fact that your SCADA is 2300 miles away being not as fast as you want is most likely not because your current Ethernet module is 100MB, it's most likely because of the intern connection + the overhead of communicating across the internet.

The first stop in determining whether or not this will be of any benefit is looking at the web page of your current Ethernet module. Check max packets per second, CPU utilization, etc.

Really though, most talk at an RPI, so you could buy the "fastest" module on the planet and it will still only talk at that RPI. They only bottle neck will be capacity (which is what the 100MB/1GB refers to). If you are already approaching the limit of connections, CPU or packets per second, then by all means, upgrade. Or if you think that you will add enough stuff in the future to approach that limit, then upgrade. But if you aren't anywhere near the limits, then you are just wasting money.

Rockwell also has an Ethernet Capacity tool that will help you determine what the load will be on an Ethernet module.

At what level of CPU utilization should I consider upgrading? My module that I looking at has about 90%. I have thought about adding another module to split the load. It connects to all my I/O as well as the optimization PC.

Oh yikes, 90% is bad. Rockwell recommends not going above 80%.

One common thing I see is that people often leave things a default RPI's when they don't necessarily need to be. For example lets say that you have a bunch of conveyors controlled by PowerFlex 525's that just run all the time, no need for really fast RPI's. Changing the RPI from the default 20ms to something more practical like 100ms or 200ms can be a big relief on the Ethernet module. Depending on how many drives, this could drop your CPU usage but quite a bit.

Sorry if I missed it, but what Ethernet module are you working with? How many devices are connected and what types?

The Ethernet IP Capacity tool will help you look at the impact of the number of devices and settings will have on your Ethernet module.

I am using a 1756-ENBT. I have a 1756-EN2T which I can install to get the added capacity. Unfortunately, I have to keep fast RPI times for most of mine since they are lugged conveyors which must keep in time, and there are diverters which must react within a 30 msec accuracy.

I am going to look at that tool, and start figuring out where I can help myself.

I am also scheduled to attend Rockwell networking classes in May, to get me up to speed beyond the basics.

The EN2T will definitely be an improvement and you definitely don't want to be operating at 90% capacity. The tool will tell you by how much of an improvement. I guess once you know by how much, you can determine if it's worth the extra money to go to the L8 series processor.

I think the port on the processor is more for programming interface than anything else. That way you can read lots of tags at the same time without bogging down the control network.

I installed the EN2T module in the chassis and created it in the I/O tree. I will need to wait until Saturday to move the connections over, no easy way to do it while we are running.
I will update next week.

UPDATE: I added the 1756-EN2T module to my chassis and moved 9 VFDs, 1 SMC Flex, and 12 Flex I/O racks to it on Saturday. I have already seen the difference in the communication. Before, I was missing 1 I/O packet about every minute or so, now that has dropped to maybe 3 per hour. I can see now how much I was really overworking the old 1756-ENBT card. The total packet rate between the two cards is ~6400 packets per second, and the ENBT is only rated for 5000. No wonder I was having so many strange issues that I couldn't explain. I have a few more nodes to move at my next opportunity, but it will now at least run without overloading the network.

dmroeder: Thanks a lot for your help. Looking at the adapter web page allowed me to diagnose the problem, and implement a solution. Thanks to you and others on this board I learn something new almost daily, even though I have been doing PLC controls for over 20 years now.