Modbus RTU and TCP

[jmir]

Hi,

On a project we have two modbus devices connected to a LM3 Lite (latest firmware), the first one is RTU port 1 and the second one is TCP.

RTU device only allows read/write one register each second, so in the profile has the field "read_delay"=1 (and it works fine). We're reading about 60 registers from this the device.
It seems that, depending on the value of "Poll Interval", the second device (TCP) is not read..
If we set the poll interval to 120s on the RTU device, then TCP is read.

Has something been changed on last firmwares? On older ones we have not seen this behavior...
How are modbus readings/writings processed? Sequentially slave to slave despite if they are on the same port or not?

We've seen that writings to RTU device are done passed some time after they are done on KNX side (sometimes after 1 minute....). How are they done after the actual polling, on the next one?

[admin]

Read delay blocks the whole Modbus mapper operation so no other read or write can happen.
Since RTU1 and TCP are shared one solution is to disable RTU1 and move your device to RTU2. This will solve the TCP blocking issue.
Writing is handled only after a complete polling cycle is finished. Does the same 1 register per second rule apply to writing?

[jmir]

Read delay blocks the whole Modbus mapper operation so no other read or write can happen.
Since RTU1 and TCP are shared one solution is to disable RTU1 and move your device to RTU2. This will solve the TCP blocking issue.
Writing is handled only after a complete polling cycle is finished. Does the same 1 register per second rule apply to writing?

Yes it's the same to write...

Are write requests queued or only last one is done? I mean, if during polling cycle we write 1-2-3 to an address, will the three values be written to the same address or only the last one?

Thanks.

[admin]

Writes are queued.

[jmir]

Writes are queued.

Ok.

We'll try to change to RTU2 to solve the reading issue.

But to understant it, if using RTU1 with a smaller slave polling cycle than the whole slave reading operation, will a second slave on the same port (or in this case the TCP slave) be read? or will it start a new poll on the first slave and the other never be read?

Thanks.

[admin]

Devices are polled in a sequence, but this also depends on the poll interval settings and how long each reading takes.

[jmir]

Devices are polled in a sequence, but this also depends on the poll interval settings and how long each reading takes.

Ok thanks!

[jmir]

Hi,

Do you have any "modbus error list" or similar?

Reading a TCP device, in the "Error log" tab (every 3 o 4 minutes) appears this message "read failed: Target device failed to respond". I'd like to know what does it mean and if there's some way to solve..

Thanks.

[Daniel]

You can increase the timeout, LM will wait longer for the answer.

[admin]

This means that the communication problem is not between LM and the Modbus device but further down the line. This error can be returned by a TCP-RTU gateway when a certain RTU device cannot be reached. Increasing the timeout might help but this has to be done not on LM side but on the Modbus device.

[jmir]

I'll try. Thanks!