I am experiencing a communication challenge between an AB CompactLogix DeviceNet Scanner module and custom slave devices over DeviceNet. The problem arises whenever the system (including the PLC, HMI, and scanner) is first powered on or remains inactive for an extended period (with all slave devices turned off). In our application for a new product, all slave devices are kept powered down until they are needed. I am utilizing RSNetWorx for DeviceNet to commission the scanner, assigning it a node address of 00, and I have configured its scanlist to include all slave devices (nodes 11, 12, 13, 14, 21, 22, 23, 24, 31, 32) in my network. The configuration has been successfully downloaded to the scanner. I am working with RSNetWorx version 5.00.00 (build 81), while the scanner's firmware is version 2.2. The CompactLogix processor I am using is a 1769-L35E, which has firmware version 13.21. In my PLC application logic, I have implemented an unconditional rung to set the run bit of the scanner's command register. Upon the initial system boot, the DeviceNet scanner indicates an error code of 79 (transmit failure), which is expected since all 10 slave devices are powered down. When I activate a single slave device by applying mains power, the scanner displays a sequence of error codes: first 79 (as mentioned), followed by 76 for node 00 repeated three times, then 78 for each slave node, and finally 75 for node 00. During this time, the scanner continually scrolls through the 78 error codes for each slave followed by the 75 code for node 00. It appears that communication between the scanner and the slave device has not been established, and the reason for this eludes me. This communication issue continues until I power down the slave device and reapply power, at which point communication is successfully established. Interestingly, if I activate another slave device while the communication issue persists with the first device, not only does communication become active between the scanner and the second device, but it also resumes with the first device. I have thoroughly examined the DeviceNet cabling and system planning documents from Allen-Bradley, and the installed cabling in my system appears to be correct to me. The total trunk line from the scanner measures approximately 3 meters. Termination resistors are installed at both ends, and I have measured 60.3 ohms across the Can_H and Can_L at the scanner. A dedicated 24VDC power supply powers the DeviceNet network. The trunk cable's shield and drain are grounded only at one end—the scanner end—where the power supply's V- is also connected to earth. I would greatly appreciate any assistance you can provide in resolving this communication issue. Thank you in advance!
Based on your description, the 1769-SDN display alternates between showing a Status Code (values greater than 63) and a Node Number (values less than 63). Upon powering up, the 1769-SDN transmits "Duplicate MAC ID Check" messages across the network. Typically, another node on the network quickly acknowledges the Duplicate MAC ID Check packet, allowing the 1769-SDN to start establishing connections with its I/O slave devices. However, in this scenario, if there are no other powered devices, the 1769-SDN continues to send Duplicate MAC ID Check packets for several seconds before indicating an Error 79. At this juncture, it stops broadcasting and awaits further action. When another device joins the network, it will generate its own Duplicate MAC ID Check message, which the 1769-SDN will detect and acknowledge. The 1769-SDN will then attempt to connect to the slave devices listed in its scan list. If it receives no responses to its connection attempts, it will display Error Codes 76 and 75. These errors are defined in the documentation as "no direct traffic detected for the scanner" and "no traffic received from other devices." Typically, I encounter Error 75 when no scan list is configured for the scanner; however, this error can also emerge while the scanner is still trying to establish connections with its slave devices without giving up. Error 78 indicates that the scanner has made unsuccessful attempts to establish a connection with a specific slave device. The scanner attempts this connection twice using Group 3 messaging and twice using Group 2 messaging, each with a timeout of one second. Consequently, you should expect to see Errors 76 and 75 for about four seconds prior to encountering Error 78. You didn't specify whether you are developing the DeviceNet firmware for these custom devices or if you are purchasing them from a third party, so I am unable to provide specific advice regarding your device. My initial thought is that there may be something atypical about your device's power-up process. Does your device implement an Autobaud detection routine? Sometimes, this process necessitates a minimum amount of network traffic. Do you have access to any network analysis software? I typically utilize A-B's DeviceNet Traffic Analyzer, but SST's software is also robust and user-friendly.
Here’s a typical example of standard power-up behavior in a network setup. In this case, we have a 1769-SDN (Node 00) and a 100-DNY42R (Node 03) connected to the same system. The 1769-SDN is configured to operate at 125 kb/s and includes the 100-DNY42R in its scan list. Upon booting up, the 1769-SDN immediately begins to transmit Duplicate MAC ID Check packets every millisecond. This process continues despite the occurrence of Error 79, persisting until the 100-DNY42R is connected to the network, at which point it sends its own Duplicate MAC ID Check packet. Once both modules verify their uniqueness on the network with two checks, the 1769-SDN proceeds to initiate a connection request to the 100-DNY42R and queries its Identity Object for electronic key validation. When you connect a new slave device, you should observe similar activity on your network. If you don’t see this behavior, please share your observations for further analysis. Here is an example of the data you might expect to see: ``` Frame # Time Can Id Grp Msg ID Mac ID Size Data 8242 0000000"000999 0x407 2 0x7 00 7 00 01 00 29 7D 0F 00 8243 0000000"001001 0x407 2 0x7 00 7 00 01 00 29 7D 0F 00 8244 0000000"001001 0x407 2 0x7 00 7 00 01 00 29 7D 0F 00 8245 0000000"001808 0x41F 2 0x7 03 7 00 01 00 8C EC 0B 1A 8246 0000000"000888 0x407 2 0x7 00 7 00 01 00 29 7D 0F 00 8247 0000000"997582 0x407 2 0x7 00 7 00 01 00 29 7D 0F 00 8248 0000000"054476 0x41F 2 0x7 03 7 00 01 00 8C EC 0B 1A 8249 0000000"946199 0x780 3 0x6 00 4 03 4B 02 34 8250 0000000"995983 0x780 3 0x6 00 4 03 4B 02 34 8251 0000001"000512 0x41E 2 0x6 03 6 00 4B 03 01 01 00 8252 0000000"000672 0x41B 2 0x3 03 3 00 CB 03 8253 0000000"008338 0x41C 2 0x4 03 7 00 4B 03 00 01 12 00 8254 0000000"000705 0x41B 2 0x3 03 3 00 CB 03 8255 0000000"010282 0x41C 2 0x4 03 6 00 0E 01 00 01 01 8256 0000000"000737 0x41B 2 0x3 03 4 00 8E 01 00 8257 0000000"010099 0x41C 2 0x4 03 6 00 0E 01 00 01 02 8258 0000000"000736 0x41B 2 0x3 03 4 00 8E 07 00 ``` Feel free to reach out if you encounter any discrepancies or need assistance!
Thank you for your responses, Ken. I didn't provide specific details about my slave devices since they are custom products being developed for us by one of our trusted suppliers. These devices are designed to maintain and enhance the DeviceNet firmware. As these devices are freshly manufactured, I am currently working on integrating my Allen-Bradley Logix 5000 application to control them effectively. It's possible that the issues we are experiencing could be linked to these devices. At the moment, I lack the necessary network analysis tools and hardware to access the DeviceNet network for communication monitoring. Today, I conducted some troubleshooting. When a communication issue arises between the scanner and the slave device—both of which have flashing green network status LEDs—I performed a reset on the Allen-Bradley DeviceNet Scanner by using the CommandRegister Reset bit, while keeping power supplied to the slave device. After the scanner was re-initialized, communication was successfully restored, as indicated by the network status LEDs on both devices turning solid green. This experience highlights the importance of reliable monitoring solutions for DeviceNet networks and suggests that proper integration testing is crucial for optimal performance.
Subject: Assistance Needed for Configuring New DeviceNet Scanner Module SDN1769 Dear Sir, I am encountering a challenge with the communication between an AB Compact Logix DeviceNet Scanner Module (SDN1769) and custom slave devices over the DeviceNet network. My name is Pradeepkumar, and I am based in Salem, India. I am currently utilizing a DeviceNet Scanner Module within the backplane of a CompactLogix processor (Model 1769-L35E). This scanner module is integrated with four DeviceNet I/O modules, five DeviceNet encoders, and five PowerFlex 40 drives. We recently acquired a new spare DeviceNet scanner module (SDNF1769) and I intend to replace the existing module with this functioning spare. I have installed the new DeviceNet scanner module into the PLC rack and connected the DeviceNet cable to its port. After downloading a functioning RSNetwork file for DeviceNet (*.dnt) to the scanner module, I attempted to go online but received an error message stating that other DeviceNet units (slaves) were not configured. Upon going online with the new DeviceNet configuration, I could only see the Scanner Module itself. However, when I access the old offline DeviceNet.dnt file before going online, I observe red “missing” indicators for all devices except the DeviceNet module. Could you please guide me on how to properly configure the new DeviceNet Scanner SDN1769 module? If possible, I would greatly appreciate a step-by-step visual guide or screenshot explanation, as I am under considerable pressure to resolve this issue. Thank you for your assistance. Best Regards, Pradeepkumar Salem, India Date: 10/04/2018
Subject: Error Code 79 on DeviceNet Scanner Module SDN1769 with Red LED Indicator Dear Sir, I am currently encountering an Error Code 79 on my DeviceNet Scanner Module SDN1769, indicated by a red LED light. Best regards, Pradeepkumar
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.