DeviceNet and AB Control Logix help needed

Hello all, I'm looking for some help with my DeviceNet. I have a 1756-DNB scanner in a rack with a Control Logix 5561 processor and my network consists of the scanner plus 5 Murrelektronic Cube67 Busnodes which in turn have some smaller Murr I/O blocks attached to them. I have six of these networks that are identical (with the exception of a minor revision on some of the busnodes) and side by side.
The problem is that on all six the scanner intermittently (about twice a day) loses communications with my node #4. The problem automatically corrects itself within about 6 seconds so I haven't been able to track it down using RSNetworx diagnostics. I have been able to capture some of the data from the scanner status registry in Logix5000 but I haven't been able to find any literature to help me decode it.
The netowk consists of almost entirely pre-fab plug and play cables with the only loose wired connections being at the scanner. Terminating resistors are in place and I have all but ruled out the grounding of the system.
Any ideas on where to start would be immensely appreciated.
Thanks.

I agree that the fact that it's Node 4 on all the systems makes it seem like it's unlikely to be an installation problem, unless Node 4 is installed differently than the other nodes (like on a too-long dropline, or with a slipring).

The 1756-DNB has some good diagnostics that can help you figure out what's going on.

Local:Slot:S.DeviceStatus[4] is the status element for Node 4. Error codes 72 and 78 are the most common failure codes for DeviceNet slaves.

Code 72 = I/O connection timed out or stopped responding
Code 78 = Explicit Message failure, including I/O connection establishment messages.

Usually I troubleshoot things like this using a 1784-PCD, the A-B DeviceNet Traffic Analyzer, and some tricks to trigger the protocol capture stop. Do you have access to any of those tools or are you close to an A-B office ?

Here's an example of how I trap Status entries in RSLogix 5000 (in version 13).

Thanks for the input Ken. I have found part of the problem to lie in my new version of RSNetworx. It apparently doesn't like the eds files that I have for my I/O blocks (the files that worked perfectly fine with the version of Networx that was used to create the network) and as a result I cannot edit or see any of the parameters for all of the blocks that attach to the busnodes. That being said, I was able to use an older version of Networx to view my entire network configuration and found some output bits that had been forced on. My guess is that they had been used for testing by the original programmer and then forgoten. These forced bits have seemingly cured the symptoms of the communication problem, but I will need to test it for a few more days before I can tell if the problem has been totally resolved.