I have two identical CompactLogix systems that function independently. Both systems utilize DeviceNet networks equipped with the 1769-SDN Series B module. I personally designed these systems and ordered the hardware simultaneously. However, only the first system was assembled initially, and it has been running reliably for over six months without any issues. Recently, I completed the assembly of the second system, which has identical hardware, software, wiring, and panel layout. Despite this, I encountered challenges in establishing communication between the 1769-SDN module and the DeviceNet network. In an effort to troubleshoot, I removed the SDN card from the first system and installed it in the second system. To my relief, the second system operated flawlessly. However, upon returning the borrowed 1769-SDN card to the first system, issues arose once again. Both cards were configured using the same scan list (utilizing the identical RSNetWorx .dnt file and PLC program across both systems). Upon further investigation, I discovered that the functional 1769-SDN card had firmware version 4.1 installed, while the non-working module had the newer firmware version 4.4. In my attempt to downgrade it to 4.1, I experienced a sudden glitch. The process was quick but inexplicably timed out midway. Multiple retry attempts yielded the same disappointing result, and after power cycling the module, I found that the 1769-SDN had reverted to firmware version 1.0. To complicate matters further, I connected my 1770-KFD to assist with troubleshooting. Surprisingly, it communicated perfectly with all my DeviceNet nodes—except for one, the problematic 1769-SDN. This module is acting temperamental, and I'm reluctant to contact the factory for support. Error codes C1C2 are appearing, and I can’t re-flash it through the backplane. I’m unsure if flashing is possible with a different PLC firmware version. The 1770-KFD does not recognize the 1769-SDN, which makes sense since it can't communicate with it. RSNetWorx won’t go online with the 1769-SDN either. While it recognizes the module in the communication path, there’s no [+] sign next to the 1769-SDN to drill down for further activation using the “OK” button in RSNetWorx. Is there any alternative method to flash this module, or is it permanently defective? I assure you that any assistance received to resolve this situation will directly benefit a local microbrewery through my donation. Cheers!
To ensure optimal performance, it's advisable to stick with CompactLogix version 4.4 (refer to the Release Notes). Previous versions of CompactLogix, specifically version 20, had a known backplane issue when working with large I/O image modules such as the 1769-SDN and Prosoft Modbus. This bug existed in versions prior to 20.018 (see Knowledge Base Article 508518, accessible to everyone). By upgrading your CompactLogix system to version 20.019, 21.x, or a more recent release, you may enhance backplane functionality, facilitating firmware uploads onto the 1769-SDN module directly through the backplane. Since you currently have version 20 installed on your system, you might want to think twice before jumping to version 21, as it represents a significant overhaul (now known as Studio 5000, coupled with major updates to RSLinx and RSNetworx). Therefore, it’s recommended to use the latest available firmware, which is 20.019, as indicated by PCDC. On a different note, I had an interesting morning scavenging by the lake's edge after last night’s windstorm, which always seems to bring up surprises from the water. Today’s exciting find was an insulated growler from Bombing Range Brewing Company, a delightful addition for local microbrewery enthusiasts.
Thank you for your response, Ken. According to the technical article, the anomaly is addressed in both the L2y and L3y models in version 21. Additionally, it has already been resolved for the L3y model in version 20.018, which is available for download on the Firmware Upgrade page. Although version 20.018 specifically targets the L3y, my CPU is the L2y. I plan to upgrade the firmware on my PLC to version 20.019 and attempt to re-flash the SDN. If necessary, I can revert the CPU to its current configuration, which is functioning properly on another system. I've had difficulty getting the SDN with version 4.4 to work on either system; however, the SDN with version 4.1 operates seamlessly on both. The SDN data tables for the scan list are relatively small, totaling just 15 bytes for all three mass-flow meters. Before I proceed with the re-flash through the back-plane, do you have any insights on why I'm unable to communicate with the SDN that currently has Firmware Revision 1.0 through my 1770-KFD? Thank you once more for your assistance. Cheers! I hope you've had a chance to explore that new discovery!
Upon reviewing the release notes for the 1769-SDN Firmware Version 4.4, it indicates that the updates are exclusively designed for the 1769-L3x and 1768-L4x controller models. Since my device is an L2x model, could it be possible that the Rev 4.4 update unintentionally introduced a bug that affects compatibility or performance with the L3x controllers?
Subject: Resolving 1769-SDN CompactLogix Compact Bus Backplane Communication Problems Hello, It seems that this technical note may be more relevant to your particular issue regarding the 1769-SDN CompactLogix Compact Bus backplane communication challenges. Access Level: Everyone. A few weeks ago, I shared a post about a similar problem related to a revision 2.2 of the 1769-SDN. It was suggested that upgrading the firmware to version 4.4 could help resolve some backplane anomalies. Based on my assessment, it looks like there may have been a misstep in your approach. Your CompactLogix 5370 L2 controller is currently running firmware version 20.012. According to the technical note, this version is known to be problematic with backplane communication when paired with a 1769-SDN device. Your 1769-SDN scanner was operating on firmware revision 4.4, which, as noted by Ken, effectively addressed these backplane communication issues. However, it seems you attempted to downgrade the 1769-SDN scanner via the backplane of the susceptible revision 20.012 controller. This action, as indicated in the technote, can under certain conditions reset the scanner module back to its factory default settings, which appears to have occurred. Ideally, the scanner module should have remained on firmware version 4.4, while you updated the controller to the latest 20.x revision. This would have avoided the complications you're currently facing. To assist you in moving forward and to avoid further errors, I recommend the following steps: 1. **Update the Controller Firmware**: First and foremost, upgrade your CompactLogix 5370 L2 controller to the latest 20.x firmware version to address the backplane communication issues. 2. **Address the Scanner Module**: The 1769-SDN requires firmware version 4.4 or higher to effectively communicate with the 5370 controllers. If the scanner module has been reset to its factory settings (version 1.0), even with an updated controller, attempting to reflash the scanner via the backplane is not supported until firmware version 3.10 or newer is in place. For flashing the reset module, you will need to utilize a direct DeviceNet interface, such as the 1770-KFD. However, it's important to note that your 1770-KFD interface is currently unable to detect the scanner module. At this point, you may be facing a critical situation. With the scanner showing an error code 99, indicating "Unrecoverable hardware failure," it's likely no longer user-flashable. You are welcome to continue your attempts, but please heed this caution—flashing over the backplane is not feasible, and it’s probable that the 1770-KFD will not recognize the scanner in its current state. It may be necessary to consider returning or replacing the device. Best Regards, George
Subject: Response to Your Points Hi George, You raise some valid arguments. However, regarding the "eggs on my face" situation, it's going to take some time for me to carefully address it and present my thoughts on a clean platter, allowing for a constructive discussion. I've learned from one of my most challenging clients that it's essential to have a cool-down period of at least 24 hours after any conflict before engaging in dialogue with the other party. Just to clarify, I wouldn't be in a difficult position if Rockwell hadn't placed unexpected obstacles in my path. I'll provide my response soon. In the meantime, I'd like to clarify that I am not the type to make unnecessary modifications to my approach just to accommodate external expectations. If that's the level of flexibility you anticipate from Rockwell, then more power to you. Best, [Your Name]
✅ 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.