DH+ Faulting when online editing

Im currently on a project involving multiple DH+ connected to a contrologix gateway.The project had an existing DH+ network with 31 slc5/04 s the site has been expanded and all the new equipment is on another 3 dh+ networks connected via the gateway.
After connecting the existing site dh+ into the gateway everything seemed ok.I recently had to do some online edits to the existing plant and this is when i started experiencing problems.When I went to assemble edits I got an error message "online edits failed" the program goes offline and then shock horror you cant see the processor in linx.When looking at the processor the DH+ led is solid red and the only way to reset the condition is to cycle power.This fault happens intermitently only when trying to edit the plcs on the that dh+.This is problem as I need to edit the existing plant but I have little confidence of whether an edit is going to bin out the dh+ or not and the operators are not happy when they lose there plant!
We also have 4 new scada polling the network and 2 existing scada so I though there might be a problem with the amount of traffic but I can understand why the problem only happens on the dh+ containing the original plant and not on any of the others

Any help much appreciated

Hi Rob,

This is just a shot in the dark but have you maybe got a conflicting node address.

traffic problems

I have seen similar problems on a DH+ network with 34 nodes. When there is much traffic through the 1756-enet/a (to desktops with rslogix running) some of the processors stop talking. It seems to me it was a timeout/refresh rate issue: the desktop stuff was eating bandwidth on an already overgrown network. Short term: we shut down unnecesary iterations of rslogix. Long term: we've shifted some critical bit level communications to relays and discussed splitting the DH+ to reduce the traffic.

Anyone else have large DH+ problems? Solutions????

We also had (have) this problem with our DH+ network. Our solution is to change over to ethernet but the true culprit of the problem is messaging. There are too many messages being sent from PLC to PLC and it's chewing away at our bandwidth. Maybe you have the same problem???

I have come to the same conclusion ozone that it is probably a problem with too many messages and have decided to try and rationalise the amount of traffic on the network which the original deisgner of the system didnt appear to look at.

Thanx for replies

Rob