We recently attempted to upgrade from an L55 processor running firmware version 15 to an L82E processor with firmware version 30. The only change made was in the processor type and the firmware revision; the program itself remained unchanged, and we are still using the same ENBT communication card. Upon testing, we encountered an issue where most messages sent to other SLC and CLX processors resulted in an error, displaying the extended error code "16#204 unconnected message timeout." Interestingly, while some messages went through successfully on occasion, the majority consistently produced this error. To troubleshoot the issue, we reinstalled the original L55 processor, and all communications worked perfectly without any errors. However, when we reinserted the L82E, the same error reappeared. I’ve searched the Rockwell knowledge base for insights on messaging problems related to version 30 but haven’t found any relevant information. As this is my first experience working with the L82E and its version 30 firmware, I am still getting acquainted with its specific characteristics and potential issues. Any suggestions or advice would be greatly appreciated!
How are the messages activated? Are they triggered by timers, counters, or at maximum speed? The L82E operates significantly quicker than the L55, which raises the possibility that a mechanism that previously functioned due to the program's delays—taking several milliseconds to re-trigger a message—might now overwhelm the buffer because of the enhanced processing speed.
The system operates on timers. Upon reviewing the data, I identified a total of 47 message instructions being activated by 30 distinct timers. This suggests that it’s possible too many timers are firing simultaneously, which could be causing the issue.
I recall there being a checkbox feature in the MSG instructions that was incorporated between the different revisions. It might be helpful to compare the MSG instructions from both the previous and the updated revision programs.
I am currently working on upgrading my L72S processor to an L82S, and it has certainly been quite the journey. Initially, I assumed that transitioning between two CLX processors would be a straightforward task, similar to my past experiences of upgrading from L6x to L7x processors without any problems. However, my local distributor helped me understand that there are significant differences between the L6x and L7x models compared to the L8X, which is fundamentally a new system. The L8X is equipped with multiple processors and utilizes a different instruction handling method, resulting in a considerable performance boost. Additionally, the software differs substantially, making this upgrade more complex. You can think of this transition as being somewhere in between upgrading from an L6x to an L7x and migrating from a PLC5 to a CLX system. It isn’t as simple as the first upgrade, but not as intricate as the latter, given that the input/output (I/O) hardware remains the same. There is a comprehensive 158-page manual that details the process for replacing an L7x with an L8X processor. I briefly skimmed through it, thinking I had grasped the critical points, but I quickly realized I needed to delve into it much more thoroughly. You can access the manual here: [Link to Rockwell Automation Literature](http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm100_-en-p.pdf). I successfully converted my program from an L72S to an L82S (version 31) with minimal issues at first. When loaded onto the new processor, it seemed functional—at least it didn’t crash. However, I faced challenges getting online at times. We eventually discovered that our Wonderware system was simultaneously utilizing both the primary and backup I/O servers, which overwhelmed the processor with excessive messages. While the L7x could manage the influx of class 3 messages by accommodating some as class 1 messages, the L8x lacks this capability, leading to communication issues. After resolving the Wonderware conflict, we tried again. Everything appeared to be running smoothly initially, but periodically, I would briefly lose connection to my safety produced/consumed tags, which triggered an emergency stop (Estop). This issue forced me to halt production. Eventually, we brought in a Rockwell Automation engineer, who discovered that some of the ENET cards were not set up for unicast communication, and not all the ENET cards had gateway addresses specified. Despite the L72S not exhibiting any issues with this configuration, the L82S did. Once the engineer made those adjustments, communication stabilized, and we felt confident moving forward. When production resumed, all seemed well for a few minutes until we encountered an error related to a MAOC instruction (if you’re unfamiliar with this term, it’s quite fascinating—look it up!). Unable to identify the source of the problem, we reverted to the L72S. After consulting with Rockwell Automation, they strongly suggested that we thoroughly read the entire 158-page manual and meticulously examine the program to identify any potential impacts. We are considering having their team assist with this due to the costs involved. Our hope is to gain valuable insights to handle future upgrades independently. I hope these insights are helpful, but be prepared for potential complexities that may arise during your conversion process. Make sure to read the manual thoroughly! As for possibilities, your ENBT setup may not be configured correctly or might be insufficient for the L8. Don’t assume that what worked with the L55 will apply to the L8. If you're utilizing any produced/consumed tags, it is crucial to STUDY the DOCUMENT. There are significant differences in how the L8x manages these functions compared to previous models. I don’t recall any MSG functions being mentioned, but they may also exhibit differences—so be sure to READ!
User mjp123gp shared valuable insights: "The messages are activated by timers. I recently reviewed and found that 47 message instructions are being triggered by 30 distinct timers, suggesting that an overload of simultaneous activations could be the issue. For my part, I initiate the messages individually by utilizing an XIO bit alongside the .En bit within the continuous task, and I’ve never encountered any problems. It works like this: MSG_1.EN-------|/|-----------------------------------[MSG_1]-------." This approach could help ensure optimal message triggering without conflicts.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: A1: The "16204 unconnected message timeout" error typically indicates a communication issue between the L82E processor and other devices, such as SLC or CLX processors. It suggests that the processor is unable to establish or maintain a connection for message transmission, leading to timeout errors.
Answer: A2: While both processors may perform similar functions, they differ in firmware versions and hardware capabilities. The L82E with firmware version 30 may have different communication settings or compatibility requirements compared to the older L55 processor with firmware version 15, which could affect message handling.
Answer: A3: Inconsistent message success could be due to factors such as network configuration, message size, or specific settings that differ between processors. It may also relate to firmware-specific features or bugs affecting communication stability in version 30.
Answer: A4: Consider verifying network settings, updating communication module firmware, checking for compatibility issues, and consulting the processor's manual for version-specific guidance. Additionally, reviewing error logs and testing different communication setups might
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.