I have about 200 powerflex drives of varies models and have a problem when the inherent problem of Ethernet shows up; that being loss of communications means no way of knowing the status of the drive.

Some devices I use have built in watchdog bits that I can monitor from the PLC. Allen Bradley drives do not have this feature. Has anyone dealt with this issue and if so, how did you remedy the problem?

 

If you are using a PLC to read the status and comm fails, the msg instruction error bit is set.

 

I have had the same problem, but luckily I only have 2 of the junk AB drives (powerflex 40's), and luckily it is on a packaging machine that stops every 5 minutes. So we just hit the e-stop (to cycle power to the drives) and go on our way. I haven't asked AB for a solution to the ethernet comms problem yet as it is low on the priority list. Hopefully, someone out there has an answer.

 

The Logix controllers do provide a (slightly clunky) way of generating a "watchdog bit" for the connection. You end up needing two rungs of ladder and two tags, one INT and one BOOL.

The first rung is a GSV instruction to class Module, instance (whatever you named the device you're interested in), attribute EntryStatus. The target of this instruction is the INT tag you created above. This gets a coded value that includes the status of the connection to the device.

The second rung starts with a MEQ (masked equal) where the INT tag is masked with 16#F000 and compared against 16#4000. That equality check will be true if the connection is running, so follow the MEQ with an OTE of the new BOOL tag to indicate the connection is running.

The EntryStatus business is documented in http://literature.rockwellautomation.com/idc/groups/literature/documents/qr/1756-qr107_-en-p.pdf, PDF page 116.

Some people on various Web forums have indicated it's best to put this logic in a periodic task rather than let it run constantly.

Hope this helps!

 

A few basic clues can be gathered from the drive's Ethernet card's Web page -- the event queue will contain events if the connection drops, and there are diagnostic items for things like receive errors and missed I/O packets. Those are good starting points. The controller and switch may also have useful statistics too.

Other troubleshooting ideas include keeping an eye on what else is happening when the connection drops -- is it always when the drive is running, for example? That might point you to a source of noise that's disrupting the comms.

Making sure you have recent firmware in that drive is also worth a look.