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
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