The larger the program, the slower Modbus becomes. (FX3U low-cost Chinese PLC)

[GcNuc]

I'm a beginner in the automation field and I've set up an automation system connecting several devices (datalogger, radio, etc.) via Modbus RS485 at 9600Kbps, with a PLC program created in GX WORKS 2. At the beginning of its development, it consumed approximately 2000 steps (out of a total of 8000 according to the PLC specifications), and I scan the Modbus using the IVRD or IVWR function along with a counter alternating readings every 1 second for each device connected to the Modbus.

The major issue is that as the program became heavier (consuming more steps), Modbus communication started to fail, and what used to take 1 second to read and write each device now takes 5 seconds for each device. The program currently has about 4900 steps.

I've already adjusted timeout times and set the transmission speed to 19200Kbps, without success, the same problem persists.

I can't find anything on the internet. Is there any possible solution or is it simply a limitation of Modbus?

 

[Steve Bailey]

I suspect it has to do with the amount of time the PLC has available to process the Modbus transactions. This is speculation on my part, but the PLC probably has a watchdog timer that gets reset every time it services the I/O. If the I/O isn't serviced before the watchdog times out the PLC faults out. The PLC probably processes the Modbus codes between the end of the time it finishes evaluating the logic and the time it must service the I/O. The longer the program, the less time available to process Modbus transactions.

 

[padees]

I don't know anything about GX WORKS 2, but a quick-relative assumption puts transactions to complete, based on number, is about 4.2 seconds.

It's rough, but at least allow 50ms between beginning to end for each transaction to exchange. This will vary based on load.

 

[drbitboy]

I suspect it has to do with the amount of time the PLC has available to process the Modbus transactions. This is speculation on my part, but the PLC probably has a watchdog timer that gets reset every time it services the I/O. If the I/O isn't serviced before the watchdog times out the PLC faults out. The PLC probably processes the Modbus codes between the end of the time it finishes evaluating the logic and the time it must service the I/O. The longer the program, the less time available to process Modbus transactions.

This seems the most likely explanation.

I think some PLCs have a parameter that can allocate what percentage of the average CPU time is spent on the user program (formerly 2000 step,s now 4900 steps) and what percentage is spent on "other" tasks, like communication. I don't know if this knock-off FX has that capability, but changing those relative allocations might help; not really sure because we don't know how many devices are being queried, or what their turnaround times are, or how many data are being transferred.

 

[parky]

The FX3 clones generally only have 8k memory availlable for the program so your program is probably not that large, on most clones the PLC parameters cannot be changed, also I do not know of a clone that supports MB directly the real FX has adapters where MB is one of the protocols so all the processing like CRC etc. is done in the card independant of the PLC it'self, also most clones are very early versions of firmware so compared to the later FX3 they are definitely slower. There are some questions is the interface an add on card like the 232/485 BD-MB or did you write your own i.e. crc etc., MB is certainly a power hungry system due to the crc generation, I did one on an FX3U as the card ordered was not the MB version, that was certainly slower than I expected, even when I recieved the correct card it was not that fast.

 

[lfe]

The FX only attends to the communications at the end of each scan and only does one thing, on one cycle it sends data, on the next it reads data, if it has arrived,
If there are several stations and the PLC scan time is long it can It take several seconds to read all stations. In a serial communication, a strict request-response-request-response .... order is followed

You can check the scan times, last, maximum and minimum in the D8000 system registers.

You can calculate how many scans will be used to read all, multiplied by the scan time you will obtain the minimum time possible to read everything.

The improvement in increasing the baud rate will be minimal, since the bottleneck is not there.
And if that clone is slower than the original FX, then even worse.