Hi everybody. I have spent a lot of time lurking on this website and have found many of the posts quite interesting and useful.
A customer that my company works for uses a 1756-L63 ControlLogix that interfaces to an Ethernet to Devicenet linking device 1788-EN2DN through a 1756-ENBT/A ethernet module. The module also services other I/O devices on remote ethernet I/O racks.
The devicenet scanner controls an MCC devicenet network controlling E3Plus overload devices, Powerflex700 drives, and simple DSA modules. The total number of nodes is about 20. The baud rate is 500kbaud. I've noticed in the Devicenet for Logix user manual that it recommends that devices that have in excess of 15 bytes of input and output data be set with low addresses, however this is not the case in this system. The scanner interscan delay is 25ms. The ethernet RPI for the scanner is 100ms.
We have a problem of the scanners input and output data registers (GP1_MCC2_DN:I and GP1_MCC2_DN:O as viewed from Logix5000) locking up and not updating. The status registers (GP1_MCC2_DN:S) continue to update, eg scan counter, device status, active node registers. When we attempt to start and stop the scanner by turning on and off the GP1_MCC2_DN:O.CommandRegister.Run bit, the GP1_MCC2_DN:I.StatusRegister.Run continues to stay on. Any motors that were running when this anomaly occurs continue to stay running, even though the outputs in the output registers GP1_MCC2_DN:O.Data are off. As you can imagine this can cause major problems due to ignored interlocks not functioning.
We can communicate using explicit commands such as the CIP message instruction in Logix5000 and monitor parameters using Networx for Devicenet, but the I/O connections will not work until we cycle power on the scanner.
This problem doesn't occur on a continuous basic. The system may run for weeks with no problem, shut down once a day, or shut down several times per day. It requires continuous monitoring from an operator, even though the system was designed to operate unsupervised.
Have you heard of this happening before? I have not seen anything on the knowledgebase about this. I would like to continue using ethernet/devicenet enabled MCC's, but if these problems persist, we will have to think of something else.
Thank you for your support.
A customer that my company works for uses a 1756-L63 ControlLogix that interfaces to an Ethernet to Devicenet linking device 1788-EN2DN through a 1756-ENBT/A ethernet module. The module also services other I/O devices on remote ethernet I/O racks.
The devicenet scanner controls an MCC devicenet network controlling E3Plus overload devices, Powerflex700 drives, and simple DSA modules. The total number of nodes is about 20. The baud rate is 500kbaud. I've noticed in the Devicenet for Logix user manual that it recommends that devices that have in excess of 15 bytes of input and output data be set with low addresses, however this is not the case in this system. The scanner interscan delay is 25ms. The ethernet RPI for the scanner is 100ms.
We have a problem of the scanners input and output data registers (GP1_MCC2_DN:I and GP1_MCC2_DN:O as viewed from Logix5000) locking up and not updating. The status registers (GP1_MCC2_DN:S) continue to update, eg scan counter, device status, active node registers. When we attempt to start and stop the scanner by turning on and off the GP1_MCC2_DN:O.CommandRegister.Run bit, the GP1_MCC2_DN:I.StatusRegister.Run continues to stay on. Any motors that were running when this anomaly occurs continue to stay running, even though the outputs in the output registers GP1_MCC2_DN:O.Data are off. As you can imagine this can cause major problems due to ignored interlocks not functioning.
We can communicate using explicit commands such as the CIP message instruction in Logix5000 and monitor parameters using Networx for Devicenet, but the I/O connections will not work until we cycle power on the scanner.
This problem doesn't occur on a continuous basic. The system may run for weeks with no problem, shut down once a day, or shut down several times per day. It requires continuous monitoring from an operator, even though the system was designed to operate unsupervised.
Have you heard of this happening before? I have not seen anything on the knowledgebase about this. I would like to continue using ethernet/devicenet enabled MCC's, but if these problems persist, we will have to think of something else.
Thank you for your support.