I have 6 modbus TCP devices in my system and one of them has consistently slow poll times.  It appears to be slowing everything down. (circled)

If I stop/disable it, everything runs quickly without any issues with latency.  However, if it is running, everything slows down considerably (presumably to its speed)

All of the important I/O is on 25ms poll intervals except the tool changer which is less critical and is on 100ms interval.  However, it appears that the tool changer is taking its sweet time and using the maximum 100ms for each function slowing everything down.

How is the "poll interval" used?  is it per connection or per function? 

I intentionally made the toolchanger 4x the interval of the other I/O thinking that there would be 3 fast acquisitions between each toolchanger acquisition.  I think this is not happening.

Is there a way to programmatically stop and start a single modbus connection? (so that I can ignore the toolchanger when it isn't needed and free the bandwidth?  I see only the command to stop and start ALL modbus.)

I've also been watching the TCP/IP traffic and it does not appear to be overloaded, it just appears that the entire modbus plugin waits the whole 400ms for the toolchanger to communicate.

Thoughts? I'd rather not start reconfiguring things on the toolchanger side but if I absolutely have to I will....

There is a way to do stop and start the who modubus plugin, a connection, or even down to the level of the function.

there is a modbus control register "mbcntl/command" which accepts the following syntax:

START | STOP | RESTART
START | STOP | RESTART <device connection>  e.g. P1_ToolChanger
START | STOP | RESTART <device connection/function>  e.g. P1_ToolChanger/function1

Not only is the register called command, it is also of the command register type.  You use mc.mcRegSendCommand()

local hReg, rc response
hreg, rc = mc.mcRegGetHandle(inst, "mbcntl/command")
response, rc = mc.mcRegSendCommand(hReg, "STOP P1_ToolChanger")
Please check the return codes.  I left them out for brevity.  The response variable has the response from the modbus plugin as to the result of the operation.  It the device or functions didn't exist, you would be notified in that response variable. 

As to the delay.  All of the device connections are run sequentially IF they meet their poll interval.  The modbus library that we use isn't multi-threaded, unfortunately.  If the tool changer device is taking too long, it will impact others, unfortunately.  You can try and streamline the calls by using the write/read multiple functions if your device supports them.  I'm not sure why some devices are so slow and don't play well with others.  I'll see if there is a way to mitigate that somehow but at the moment, I can't think of anything other than what I suggested with the multiple read/write functions and your idea of starting and stopping device connections.

Steve

Thanks

I’ll try that out.  I had a feeling that some command existed because the register was there.

I currently use the rc from one input on each module as a ‘health indicator’ to see if everything is happy. I noticed that at least for the advantech modules that i have the overall rc for a device will still show OK if it is not connected sometimes or times out. 

However, if i select one of the inputs and monitor that rc it works great.  I have a function in my toolchanger macros to check the modbus i/o before relying on an input from there.

There is a known bug (feature?) Of one of the arduino modbus libraries that is used by my PLC that limits the number of successive registers that can be read to 7, so unfortunately i needed to have a number of functions instead.  Otherwise the other modules have one function for reading all and one for writing all.  That could be why they are so fast.

I’ll play around and report back

Thanks, That worked a treat.  Now I have to integrate that into my M6 to turn on the Tool Changer modbus before needing to use the changer.

I noticed that the "scan denominator" field in the MB config tool does not show the correct current value from the machine.ini file.  I have now set the scan denominator to 4 (in the ini file) on the read functions and put the poll interval to 52ms and now my everything is fast (enough).  The only (minor) downside is that now my TC MB OK indicator doesn't work because the RC for the TC input functions flashes back and forth.  Not a big deal.  The more important I/O is still fine.

I noticed that the functions taking the longest time are actually the write functions, not the read functions.  it doesn't look like they are being executed, perhaps just reported in the MB diagnostics page.  Are the functions only run if there is a change in the registers that are to be transferred? (if so, excellent) 

Great thread! For others facing similar issues, here are 2 additional optimization tips:

Batch Processing: If your devices support Modbus function code 23 (Read/Write Multiple Registers), this can reduce round-trip latency by up to 40% based on my tests.

Selective Polling: As suggested by smurph, dynamically enabling/disabled non-critical devices (like tool changers) during idle periods via mc.mcRegSendCommand() is brilliant. I've implemented this with a 15% throughput improvement.

@brianthechemist: The write function latency you observed might be due to TCP ACK delays. Some PLCs implement write coalescing (as you suspected) - worth checking your device's Modbus stack documentation.

P.S. For Arduino register limits, consider splitting reads into overlapping batches (e.g., registers 1-7 then 5-12) to maintain data continuity.                                                                block blast

Have you tried logging the exact response time of each slave? Is the problem with the slow response of the toolchanger itself or is it that the Modbus master is processing sequentially and does not support multithreading?