A B ML1500 PLC comms fault

The Micrologix1500 PLC lost comms when trying to function valves from the HMI. Cycled power to the PLC, and restarted the HMI, and comms came back.

Anyone know of any known issues with the PLC dropping out unexpectedly?

The PLC is about 5 yrs old now, so I was thinking that maybe there's probs with the battery, or some sort of power supply probs...
The values being read on the HMI are passed through the DeviceNet Scanner, could there be a prob with the W/1769-SDN?
Checked cables, these were OK.

I'm new to AB's so I'm not sure where to begin diagnosing. Can RSLinx be used to help diagnose comm faults?

Cheers.

What's the part number of the PLC? Is it perhaps a DC model, with the valves also being DC - powered off of the same power supply? Are the DC valves(?) power off the same power supply as the DN?

What kind of HMI device is it ?

Did the controller actually fault, or did something go wrong on the DeviceNet ? Examine the LEDs on the controller itself as well as the 2-digit display on the 1769-SDN.

My first guess is that the valve action disrupted the DeviceNet.

With DeviceNet, the first three troubleshooting steps are straightforward:

1. Check the 24VDC power at the power supply and at the furthest away node. You need less than 5v drop, and the power supply must be dedicated to the DeviceNet network only.

2. Remove the 24VDC power and measure resistance between the blue and white wires. You should have about 60 ohms if the two termination resistors are properly installed.

3. When the problem occurs, take a look at the LEDs on the DeviceNet scanner and write down the values (even if it's cycling through several). These provide crucial troubleshooting information.

I know you said the PLC is 5 years old... But just to be clear, has this system as you have it configured now ever worked? That is, are we troubleshooting a failure of a running system or a new system?

If it's a new system, you broke a rule already (see Ken's post item #1). The DeviceNet power supply must be dedicated to the DeviceNet. That means you can't power the PLC processor from it, and certainly can't power the I/O from it.

You may get away with powering everything from one supply, but if it's not working, it's one of the first things to eliminate.

Next time this happens, get out a pen and paper and write down the conditions and colors and labels of all the LEDs on all the components (the MicroLogix, the 1769-SDN, the 1794-ADN).

It would also be interesting to know if the Wonderware computer displayed any sort of informational message.

One of the principles of having the network devices get their power from the network cable is isolation.

Consider an AC drive. If the network device gets its power from the same control power as the drive, that's a way for noise to get conducted onto the network and then to the other devices connected to the network.

The same principle applies to simpler discrete I/O; solenoid valves are famous for inducing voltage spikes into the power bus that feeds them. Having the network connected to that same power bus would mean those disruptions travel over the network cable.

The only devices that are actually part of the DeviceNet network are the network half of the 1769-SDN scanner and the network half of the 1794-ADN adapter. Everything else is separate from the network.

I've been working with DeviceNet since 1996 and have seen dozens of OEMS listen to my lectures, read the design guide, nod their heads in understanding and then totally ignore this simple principle. Some continue to do it after installing systems that work very poorly because of it. I guess the temptation to save money on just one small DC power supply must be overwhelming.

I strongly recommend the addition of a properly-selected DeviceNet power supply that only provides power to the DeviceNet.