As a novice in the field of automation, I have successfully established an automation system that links multiple devices (such as a datalogger and radio) through Modbus RS485 at a speed of 9600Kbps. The system is supported by a PLC program developed in GX WORKS 2. Initially, the program utilized around 2000 steps out of the specified 8000 steps, and I monitored the Modbus communication by utilizing the IVRD or IVWR function along with a counter that switches readings every second for each connected device. However, as the program grew in complexity and consumed more steps (currently around 4900 steps), the Modbus communication began to encounter failures. What used to be a quick 1-second read and write for each device now takes about 5 seconds. Despite adjusting timeout settings and increasing the transmission speed to 19200Kbps, the issue persisted. I have searched extensively online for a solution to this problem but have not found any. Is there a viable solution to this issue, or is it simply a limitation of the Modbus system? Any advice or guidance on this matter would be greatly appreciated.
It is likely that the performance of the PLC in processing Modbus transactions is influenced by the available time for processing. My assumption is that the PLC is equipped with a watchdog timer that resets whenever it handles the I/O tasks. If the I/O tasks are not completed before the watchdog timer expires, the PLC will encounter faults. The PLC likely prioritizes processing Modbus codes after evaluating logic and before fulfilling I/O tasks. As the program lengthens, the PLC has less time to dedicate to processing Modbus transactions effectively.
While I don't have much knowledge about GX WORKS 2, an estimated transaction completion time is approximately 4.2 seconds based on the number of transactions. It's a rough estimate, but it's advisable to allocate at least 50ms for each transaction exchange from start to finish. Keep in mind that this timeframe may vary depending on the workload.
In my opinion, the issue may be related to the processing time of the PLC for Modbus transactions. It is possible that the PLC utilizes a watchdog timer that needs to be reset each time it handles I/O tasks. If the I/O tasks are not completed within the specified timeframe, the PLC may experience faults. The PLC likely prioritizes processing Modbus codes after evaluating logic and before servicing I/O tasks. As the program length increases, the time available for processing Modbus transactions decreases. Some PLC models offer a feature that allows users to adjust the allocation of CPU time between the user program and other tasks like communication. It is unclear if this FX model includes this feature, but modifying these allocations could potentially resolve the issue. However, without knowing the number of devices being queried, their turnaround times, or the volume of data being transferred, it is difficult to determine the most effective solution.
The FX3 clones typically come with only 8k of memory for the program, indicating that your program is likely not very large. In most clones, the PLC parameters cannot be modified and support for MB directly is not available. The authentic FX has adapters that support MB as one of the protocols, handling processing such as CRC independently of the PLC itself. Additionally, most clones have firmware versions that are older and slower compared to the later FX3 models. Questions to consider include whether the interface is an add-on card like the 232/485 BD-MB, or if you wrote your own code for CRC, etc. MB is known for being power hungry due to its CRC generation, which can impact processing speed. In one instance, using an FX3U without the MB version card resulted in slower performance, even after eventually obtaining the correct card.
In a PLC system, the FX unit handles communications at the end of each scan by alternating between sending and receiving data. When multiple stations are involved and the PLC scan time is lengthy, it can take several seconds to complete communication with all stations. A strict order of request-response is followed in serial communication. Monitoring the scan times, such as the last, maximum, and minimum, can be done in the D8000 system registers. By calculating the number of scans required to communicate with all stations and multiplying it by the scan time, the minimum time needed for communication can be determined. Increasing the baud rate may yield minimal improvements, as the bottleneck does not lie there. Additionally, if a cloned FX unit operates slower than the original, communication delays may worsen.
It appears as though you've dived deep into this! Given your description, the latency issue might indeed be due to the increased complexity and consumption of PLC program steps. However, Modbus RS485 itself isn't typically limited in this way. You might want to explore partitioning your program into smaller subroutines or optimizing how it's structured, as bulky code can cause significant performance drops. Additionally, you might consider using more advanced PLCs that can handle greater program complexity without slowing down. Remember, while increasing transmission speed can help, efficient code remains key to an agile system. Hope this helps. Stay persistent!
Firstly, kudos on your achievement in mastering automation as a novice. It sounds like you've set up a pretty intricate system! It's quite possible that the delay you're encountering could be related to the growing complexity of your PLC program. When your program only used a fraction of its steps, the Modbus communication was probably more efficient because it had fewer tasks to handle. As you added more steps, the system had to manage more data, causing a delay. This isn't inherently a limitation of the Modbus system, but rather a consequence of program complexity. However, there could be other factors at play such as issues with RTU (Remote Terminal Unit) or network inefficiencies. I would recommend testing segments of your program individually to isolate the issue. There's also a chance that you might need to consider a system with greater step capacity if your program keeps expanding. Keep persevering - automation troubleshooting is often a complex puzzle, but there's tremendous satisfaction in finding the right solution. Good luck!
It sounds like your system may be suffering from the limitations of the Modbus protocol itself. Modbus is not the fastest protocol and doesn't handle large amounts of data efficiently, especially as the complexity of your system increases. The first thing that I would check is your Modbus polling rate. You can adjust this rate to suit your needs. Also, you could look into optimizing your Modbus map by separating your input/output registers and only polling those as required. It might be worth exploring more robust protocols such as OPC UA or MQTT if efficiency and speed are crucial to your system. Remember, Modbus has been around for a while and while it is a stable protocol, it doesn't compete with more modern ones when it comes to managing large data flows.
It seems like your program's complexity may be pushing the boundaries of what the Modbus RS485 can handle effectively, but don't rule out other issues just yet, as there could be multiple factors at play here. First, you could try optimizing your PLC program; though it's developed in the powerful GX WORKS 2, it might still have unnecessary operations or calculations that are taking a toll on your data transmission speed. Secondly, consider the physical aspects of your setup – long cable runs, poor quality cables, or a high level of electrical noise can all cause communication hiccups. Finally, you could look into adding some delay between each device read/write sequence to give your devices and the Modbus a breather, which might improve performance. That said, remember that while Modbus is a sturdy communication protocol, it does have its limitations, especially when dealing with complex systems and high speeds. Don't rule out upgrading to a more robust communication standard if these attempts don't remedy the issue.
It sounds like you’ve made great progress with your automation system, but I can see how the increasing complexity is throwing a wrench in your Modbus communication. One thing to consider is the overall load on your PLC; as you're filling up your available steps, the processing time for each command can definitely increase, leading to a slowdown in communication. Have you thought about optimizing your code or breaking up the tasks into smaller, more manageable segments? Also, implementing a proper polling strategy—like reading multiple values with a single command where possible—could help you reduce the communication load. Sometimes, simplifying your approach with batching can dramatically improve response times!
✅ 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: The slowdown in Modbus communication could be due to the increased complexity of the program which consumes more steps, leading to longer processing times and delays in data exchange.
Answer: Answer: While adjusting timeout settings and increasing transmission speed (e.g., from 9600Kbps to 19200Kbps) may help in some cases, it may not completely resolve the issue if the program size and complexity are causing significant delays.
Answer: Answer: The slow communication issue is more likely related to the program size and complexity within the FX3U PLC rather than being a limitation of the Modbus system.
Answer: Answer: To address the slowdown, consider optimizing the PLC program, reducing unnecessary steps, improving communication efficiency, and possibly implementing asynchronous communication methods to enhance data exchange speed.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.