ControlLogix / RSNetWorx backplane issues with third-party DeviceNet slaves

[kbhit()]

I frequently get called on to integrate various vendor equipment using open networks such as DeviceNet.

Whenever I come across systems that use Allen Bradley's ControlLogix PLC, with the 1756-DNB scanner with third-party products such as Symcom's Motor Saver, or more recently Eaton's C441 Motor Insight, a particular scenario always causes a great amount of grief.

If the network of slave devices is configured directly on the DeviceNet network by connecting with say, a KFD module, or Eaton's CHStudio software, everything works great. I can setup the slaves, bump motors from the software, etc. Then I connect the DNB to the network, load the scanlist with the commissioned nodes, and all is well.

If, however, I try to commission the nodes via RSNetWorx in the control room for instance, out over ethernet to the processor, through the backplane to the DNB, then all hell breaks loose.

What happens is that IO sizes don't get registered properly, nodes appear and then disappear, and days are spent in frustration trying to get things to work, usually all to no avail.

Once I get fed up and take my laptop out to the field and fire up RSNetWorx while connected directly to the network, once again, everything works PERFECT.

This has led me to believe that there is a particular issue with communication in the backplane that is not tested by third-party manufacturers. I say this because all of the Allen-Bradley nodes integrate beautifully, while the third party nodes do not. I have heard from others that they have experienced this same issue, and I have also heard that certain third-party manufacturers such as Mitsubishi do NOT suffer this problem, but that is anecdotal information since I have never commissioned Mitsubishi nodes.

I would like to hear from other users on their experiences integrating third-party DeviceNet nodes into a ControlLogix system. Did it go well?

Regards

 

[Ken Roach]

Welcome to the Forum, and thanks for the well-written first-time post.

What you are describing is consistent with what I've seen with a lot of third-party devices that don't implement the Un-Connected Message Manager (UCMM) object, or that otherwise support only an explicit connection or an I/O connection, but not both.

Sometimes it happens with devices that have a simple I/O object that you can easily get configured correctly in the 1756-DNB scanlist. Once those devices have an I/O connection established, though, they no longer support an explicit message connection, or no longer support an explicit message connection from the same device as the I/O connection. You have to either connect using a different interface (like the 1770-KFD) or you need to break the I/O connection.

A similar situation happens when you have a device with a complicated I/O assembly and you get the Scanlist I/O size wrong, resulting in an E#77 error code on the 1756-DNB. The device doesn't know any better: as far as it's considered, it has created an I/O connection and that connection is in the Idle mode. But the device doesn't support both an explicit message connection and an I/O connection, so you can't get online with it to modify the configuration and resolve the E#77 error.

Most A-B devices don't have this problem because they've been designed from the beginning for simultaneous explicit and I/O messaging, or because they support the UCMM (AC drives, in particular, are good with unconnected messaging). RA does a lot of interoperability and conformance testing.

My most frequent technique to deal with these is to un-check the 'Active' box in the Scanlist entry to disable the 1756-DNB's attempt to create an I/O connection. This can be done online in RUN mode with modern 1756-DNB's (after v5, I think) that support Online Scanlist Changes at Runtime.

Some devices don't reset their I/O connection state to 'Not Established' until they get power cycled, though, and instead leave it as 'Faulted' and you have to go power cycle them to get back online with them. I've installed extra circuit interruption to my DeviceNet power in the past to speed up the power cycles to the network when dealing with stuff like that.

 

[Ken Roach]

Oh, and Mitsubishi doesn't get a pass from me. It's been a long time since I commissioned their first generation of DeviceNet interface for their large-frame AC drives, but I remember very clearly that when the DeviceNet connection broke (because the PLC went into Program Mode or faulted), the drive kept running at speed.

When I tested and documented this issue, the response from Mitsubishi's sales manager was "DeviceNet is Allen-Bradley's problem".

 

[kbhit()]

Hey Ken,

Thanks so much for your timely and informative reply on this!

I'm glad to hear there's at least one other out there who have experienced similar issues and possibly a solution. I have a Rockwell rep coming out to site this Thursday to see if there's something that can be done to alleviate this particular issue... will pass along this information.