I have been experiencing intermittent CIP explicit messaging problems while working on my machines. To address this issue, I decided to consolidate small MSG instructions into one block message that activates every 25 milliseconds. This block consists of a read block of 25 DINTs and a write block of 25 DINTs. In addition to the troublesome machine with a 1756-L61s, I also manage PLCs for a draw furnace (SLC 5/05 with integrated Ethernet port) and a hot setting machine (1756-L55). All three machines are connected in a star configuration using a Netgear switch. Despite efforts to troubleshoot by testing temporary Ethernet cables and observing a 4th machine communicating without issues, the MSG instructions continue to stall simultaneously. Could this be due to network overhead? Communicative issues can be complex and challenging to pinpoint. Thank you for any insights you may have.
I understand that identifying communication issues can be challenging. Utilizing managed switches can be beneficial, especially when dealing with physical network problems. Some important questions to consider when troubleshooting technical support include: What specific model of 1756-ENxT module are you using with the 1756-L61 processor? Have you assessed its connection capacity, packet load, and hardware interface errors? Does your logic execute MSG instructions every 25 ms under specific conditions, or solely based on a repeating timer? How many MSG instructions are incorporated in your program? Have you monitored for .ERR and .EXERR values if the MSG instructions end with a .ER bit? Do you manually set a time-out for MSG instructions, or have you adjusted the default time-out from 30,000 ms to a shorter duration?
Correction: All my messages are triggered at a 250 ms interval, not 25 ms as previously stated. I am currently working with an 1756-EN2T Rev 2.001 module and setting up new MSG instructions. These instructions are structured in a similar way, with approximately 30 of them running on the PLC. However, I have yet to delve into the connection capacity and other related details, which I plan to explore further through additional reading. During a recent check of the diagnostics page, everything appeared normal, with no issues related to out-of-order packets or collisions. Despite this, I have noticed that the messages sometimes hang without any error messages appearing. In an attempt to address this issue, I previously implemented a manual timeout but ultimately removed it as it did not address the root cause. I am considering grouping the MSG instructions into blocks to optimize their firing at intervals, as the current setup is not ideal in my opinion. I have attached some screenshots from the diagnostics page for reference.
Is it worth updating the firmware version to improve packet capacity? Upgrading the firmware may enhance the device's performance and boost packet capacity.
To optimize message processing, it is recommended to set up MSGs in a sequential order and trigger them one by one using their .DN or .ER bits to initiate the next MSG in a cascading manner. It is advisable to adjust the Timeout value for each MSG to a shorter duration to prevent a 30-second delay in case of failure. This approach ensures that only one MSG is active at any given time, allowing them to run efficiently and prevent overflowing of the communication buffer. This method helps in improving the overall performance and reliability of the system.
TheWaterboy proposed a method for optimizing message sequencing to avoid overwhelming the messaging buffers. By setting the MSGs in a sequence and triggering each one based on their .DN or .ER bits, you can create a cascade effect with minimal wait time. It is recommended to set a smaller Timeout value for each message to ensure they run efficiently without filling up the communication buffer. This approach ensures that only one message is active at a time, allowing them to run quickly and preventing buffer overload. If you encounter difficulties switching modes from run to program, it may indicate that your message buffers are full.
✅ 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: Answer: Intermittent CIP messaging issues could be caused by network overhead, among other factors.
Answer: Answer: One approach is to consolidate small MSG instructions into one block message that activates at regular intervals.
Answer: Answer: Simultaneous stalls in communication could still persist due to underlying issues like network overhead affecting multiple devices.
Answer: Answer: The star configuration setup using a Netgear switch to connect multiple PLCs may introduce network overhead, potentially contributing to communication problems.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.