Modbus Read/Write Instruction: Best practice?

Lately, I've been using Modbus for reading sensor values in process programming. I haven't used Modbus much, so I spent some time looking at examples of doing Modbus read/write instructions in different PLCs. One thing I've noticed is that there are different ideas about instructions *before* the Modbus instruction. I've seen:

Nothing prior to instruction... read happens every scan.
*Not* Read Error, or 1 second after a Read Error
First scan, or successful completion of read/write, or read/write error
Timed read/write... 500ms.

So I'm wondering about "best practices" for Modbus read/write instructions. Is there such a thing? Is there a reason to slow down the read/write instruction? Does it really affect scan times that much? Why would you put anything at all? Any thoughts on this? What do you do? Motion control has different considerations than process, but does it warrant different practices? This would be a concept I'd like to resolve... it's sort of a speed-bump for me as I try to think it through.

I attached a screen shot of my latest Modbus lab in CCW for an example. This is Modbus RTU on a temperature controller.

I typically program Modbus (or any other) message instructions to run at a programmed rate where I trigger the messages in a controlled sequence with an adjustable delay between each message. In some cases (with radio polling) I will manipulate the timeout settings so I can shorten the overall poll time when errors occur.

I have not worked with CCW, but in most A/B PLCs, the MSG instruction will execute once on each false to true transition. In a Click, the Send and Receive instructions will execute repeatedly as long as the rung is true.

I have worked with some devices that will brain freeze if you beat them up with too many Modbus requests in rapid succession, so I almost never go as fast as physically possible, but usually poll at a rate that will not break anything and is plenty fast enough to deal with the control I need even if an occasional error or two occurs and slows it down a bit.

Paul,

"Programmed rate"... any examples? 200ms? 500ms? I'm lacking the experience to make a judgment. Then, if you have a 200ms interval, what would you set for timeout?

It depends. If I have 4 VFDs hardwired RS-485, I might have my "inter-message delay" set at 50-100ms and the timeout set to 1 second.

If I am polling serial radio modems I will set my timeout at 3 to 5 seconds and I often make the inter-message delay an HMI tag with an adjustable range of 0.1 second to 5.0 seconds.

This has been especially handy with Phoenix TWE series radios where I can slow down the polling and use a web browser to log into a remote radio modem to do a backup, edit its configuration etc. These are ethernet, not serial, but we use Modbus TCP messages to poll them where used with I/O extension modules and if I slow down the PLC polling, there is enough dead air time that a web browser can display the details from a remote modem.

We have some other systems where we found out (the hard way) that certain RTU boards were not liking it when we had too short of a delay between messages, and yet another system that we slow down at night to save energy at water towers with solar powered RTU panels.

Also, with radio polling, I will write my sequence so that I can skip stations that are out of service if, for example, a water tower is being recoated or a pump station is shut down for a day due to a pipe break.

I use the DONE or ERROR bit from the previous block execute the next, this is in Siemens TIA portal.

I've seen Allen Bradley example in RsLogix polling without this and just poll every scan, I took over a program that had it done this way and the VFD froze every now and then. I implemented the Done or Error and problem went away.