Backplane drop out over ControlNet

I have a few Lonworks and Modbus cars in a remote ControlLogix rack via controlnet. About once a week or so these cards lose their backplane connection to the PLC and I have to pull out and plug them back in to reinitialize comms. In trying to figure out why, I notice all of the I/O cards on the controlnet network use an RPI of 200ms. We're talking two remote racks with 23 cards total. The NUT is 5ms. Could this be causing the issue?

Within a 5ms Network NUT, a 200ms RPI configured module will be updated at 160 ms; the API (Actual Packet Interval) of a CNet networked module is NUT X 1, 2, 4, 8, 16, 32, 64, 128, hence for a 5ms established NUT the actual packet updates will be only one of the 5, 10, 20, 40,80, 160, 320 or 640 ms intervals.
If you could "take" a lower RPI rate for the troublesome modules, I'd try "requesting" the modules' packets at 320ms.
If this is not acceptable, I would gradually try increasing the network's NUT in 1ms increments; maybe a 6ms NUT will solve the issue since you will be using the "32" multiplier instead of the "64" one.

dmargineau said:

Within a 5ms Network NUT, a 200ms RPI configured module will be updated at 160 ms; the API (Actual Packet Interval) of a CNet networked module is NUT X 1, 2, 4, 8, 16, 32, 64, 128, hence for a 5ms established NUT the actual packet updates will be only one of the 5, 10, 20, 40,80, 160, 320 or 640 ms intervals.
If you could "take" a lower RPI rate for the troublesome modules, I'd try "requesting" the modules' packets at 320ms.
If this is not acceptable, I would gradually try increasing the network's NUT in 1ms increments; maybe a 6ms NUT will solve the issue since you will be using the "32" multiplier instead of the "64" one.

Click to expand...

But that would still have all of the I/O updating at the same time. I guess my real question is if its causing problems to have all of devices updating at the same time.

I don't believe having all the I/O RPIed at the same intervals is the issue here (they are not quite updated at the same time but at identical intervals); having the I/Os excessively RPIed could be an issue.
I'd try first increasing the NUT to 6ms; I don't think a 1ms increase will cause network issues, however the respective modules will be RPIed at 192ms instead of 160.

I remember a few occasions in which decreasing the NUT has solved bandwidth issues since fewer modules will be updated within one network period.
This being said, Rockwell's recommended mitigation is increasing the module's RPIs.

I wouldn't go changing RPI or NUT values until you understand the nature of the problem.

Are these scheduled or unscheduled connections ?

Are there scheduled connections to other modules in these two backplanes ?

Are there Rack Optimized connections to these two backplanes ?

Are there any diagnostic LEDs or displays on the modules themselves that might tell you about the nature of their disconnection ?

Have you examined the diagnostic counters on the ControlNet modules (both at the controller side and at the remote chassis side) to find out if there are signal quality problems on the network ?

What is the CPU Utilization of the ControlNet module on the controller side ?

The whole point of ControlNet is that data is scheduled and bandwidth is reserved, so you get reliable communications unless there is a physical disruption of the signal.