CLX Backplane Limitation?

I usually come to this forum and find the answers I am looking for by looking at the previous posts, threads etc. Then go away happy.
I seem to be struggling a bit with this one.
I have just added two remote racks off my main control logix rack using enet distributed I/O, rack optimisation etc. This went really well. No problem so far. I calculated the packet interval into this module from the other remote modules at 2000pps. (Slot 1 main rack)
Now my electrical colleague thinks he is getting the hang of this, by planning some extra racks! What are the limitations?
I understand that the 1756 ENBT can handle 5000pps, (leaving some spare as suggested) but say I add another 1765 ENBT in (Slot 2 main rack) and hang another couple of racks off this?!? I seem to remember reading somewhere that the backplane can only handle so much data. Where can I find this info?
Thanks
Ben

I think this is a good example of Ethernet I/O misapplication. First, this should be controlnet - you would not guess will system work or not. Rsnetworx would tell you.

Second, 5000 packets/sec can be achived only at certain packet size and not the only indicator. Look at ENBT CPU usage as well.
Processor and the backplane can be another bottleneck.
2000 pps is already way too high IMHO.

Assuming that system works now and nothing else going over ENBT, you should double RPI for existing racks and add another ENBT to talk to new racks.

I agree with Contr_Conn. Remote I/O is MUCH more predictable on ControlNet than Ethernet. It would be a much better way to go.

As stated by Contr_Conn, if you use ControlNet the software won't let you get in trouble. In my experience once the network is scheduled it is "rock solid". ControlNet is your best bet for remote racks on Controllogix.

That said, There are a lot of other factors in determining ENBT loading than just the frames. ENBT processor loading, Number and type of connections. I am not an authority on ENBT traffic. I stay away from Ethernet based I/O in general.

If you are going to use Ethernet again for more I/O, I would do a lot of reading up on the subject.

Evaluate your RPI's if you did not change them they defaulted at a ridiculously low value. (5ms I think) If you set your RPI's to what is needed and no faster you will reduce your traffic a lot.

If you are only using the original ENBT for "scheduled type traffic" then it should easily handle more I/O. If you are using this ENBT for HMI's and or data collection too, then you really need to add another ENBT and seperate the 2 types of traffic. Since Ethernet is 1st come 1st serve the hit and miss traffic from an HMI can cause mischief with I/O data that is time sensitive. If you seperate the 2 types of traffic then your I/O on Ethernet will become somewhat deterministic.

Please note all the "if's" above. you can use Ethernet to do what you want, you just have to be smart about it. In general It really is a mis-application IMHO.

I have never seen application where the backplane was the bottleneck. We have an application that has 2 processors, 3 ControlNets, 2 Ethernets, and local I/O all in the same rack. It is very stable and has a LOT of communications taking place across the backplane.

I was told by a Rockwell engineer/integrator that the backplane was by far the most robust communication bus in the system. He was unable to be more specific though. If anyone has seen the actual specifications for data throughput I would be interested myself.

RSL

Some years ago I recall an AB Engineering type giving a presentation on CLX. At some point he mentioned that they attempted to measure the upper limit of the backplace total data transfer, and found that with any practical configuration they could not break it. I vaguely recall him saying that the upper limit was theoretically around 80-100 MBytes/sec. ( I stress that this could be quite wrong.) Confirming this we see that none of the manuals seem to point to any limit on the backplane either.

This of course is quite distinct from the limits of the comms/processor modules themselves. So far I agree with your thinking. If the average pps is getting up to around 50% of the ENET's throughput I would also be considering a second ENET.

Although I would generally prefer CNET for remote I/O, there is nothing wrong with a correctly engineered ENET solution either.