FC-16 Write Multiple Holding Registers fails about mbusd HOT 18 CLOSED

Closing issue, the code change corrected this. Thanks again

from mbusd.

modbus.zip

Adding zip illustrating the failure

from mbusd.

I have same problem. I use Eastron SDM120-Modbus. It uses 32bit float.
Reading (03 - Read holding registers) is OK.
But writing of the same registers (16 - Preset multiple registers) fails.
mbusd_err16.txt

from mbusd.

@sgel83 hmm, actually mbusd supports multiple registers reading/writing (function codes 03 and 16) and it should work, but for specific devices your mileage may vary. I've checked your logs and see many lines with "tty: dropped bytes" message. That's quite unusual, are you sure mbusd is single master on the Modbus RTU network?

@zmata it looks like your device doesn't respond to the request. Could you try to perform the same request using some other master RTU software directly connected to your device?

from mbusd.

Hi Victor,

Thanks for taking a look at this. Here is a new log without the secondary master on the RS-485 network. The behavior of the app is still the same where it fails to write. I actually think it is similiar to zmata, as you will see in the wireshark trace it shows the gw is not responding.

This shouldnt be the case though because if I stop mbusd and use pymodbus I can change the value using FC-16 without an issue.

single_master.zip

from mbusd.

Hello @sgel83, thanks for the log files, I've checked .pcapng file and it looks like fc16 request is malformed:

It seem the root cause of a problem is invalid Modbus/TCP length field, while actual encapsulated Modbus frame size is 9 bytes, the length field indicates it's only 6 bytes long. That looks quite odd. What kind of Modbus TCP master software you're using?

from mbusd.

Its an android app for a centralized ventilation system:

https://play.google.com/store/apps/details?id=com.Amalva.c4_app

According to the reviews it works but maybe thats how they keep the customer from using other gateways, they just look at the data size in the packet instead of modbus/tcp length header.

Good catch.

from mbusd.

I use Simply Modbus TCP Master. It's free, and super useful. They also have Simply Modbus RTU, to test RTU devices.

from mbusd.

My log is from test with Simply Modbus TCP Master.
If I use Simply Modbus RTU for direct writing registers - succes.
If I use Loxone Smart Home miniserver to send through MBUSD, it fails (same as Simply Modbus TCP Master)

from mbusd.

@zmata, I think we have different issues though. My issues is the client app is misbehaving by not calculating the mbdata length correctly for the mbtcp length header. If I use pymodbus as a TCP client to write the same register message (but with the correct size in the length header) it is working..

@3cky Are you open to the idea of adding graceful handling of this type of situation where it reads the mbus data and calculates the length? Or do you think its too much of a performance hit?

from mbusd.

@sgel83 still thinking about the best way to handle this type of situation gracefully. There are some options, will look into them.

from mbusd.

@3cky Great, in the meantime I also emailed the manufacturer, and requested them to fix it. No feedback yet.

from mbusd.

Regarding my problem, that is definitelly another then one by @sgel83
Everything is ok using Simply Modbus TCP Master. I can write 16 - Preset multiple registers. It was problem in my configuration of the Simply Modbus TCP master before - I'm sorry.
But it fails using Loxone Smart home Miniserver.
I tried to sent same command from Loxone and Simply Modbus TCP Master through MBUSD, receiving it by Simply Modbus TCP Slave. I sent value 2 (32bit float) to address 40029. There is result:

From Loxone:
2018/04/12 12:34:27 >>> 01 10 00 1C 00 02 04 00 00 40 00 C3 36
2018/04/12 12:34:28 >>> 01 10 00 1C 00 02 04 00 00 40 00 C3 36
2018/04/12 12:34:28 >>> 01 10 00 1C 00 02 04 00 00 40 00 C3 36
2018/04/12 12:34:29 >>> 01 10 00 1C 00 02 04 00 00 40 00 C3 36

From Simply Modbus TCP Master:
2018/04/12 12:28:16 >>> 01 10 00 1C 00 02 04 40 00 00 00 E7 36
2018/04/12 12:28:16 >>> 01 10 00 1C 00 02 04 40 00 00 00 E7 36
2018/04/12 12:28:17 >>> 01 10 00 1C 00 02 04 40 00 00 00 E7 36
2018/04/12 12:28:17 >>> 01 10 00 1C 00 02 04 40 00 00 00 E7 36

It seems to be caused by "Low word first". But there isnt possibility to change it in the Loxone configuration.
Would it be possible to implement function into the MBUSD to change it according to some parameter?

from mbusd.

@zmata It seems that its possible to change the behavior of Simply Modbus TCP Slave, have you tried this?

http://www.simplymodbus.ca/RTUSlaveManual8.htm
Section "The Simply Modbus Slave Window"

You have 2 check boxes:

"High byte first"
"High word first"

http://www.simplymodbus.ca/FAQ.htm
It outlines 4 possible configurations:

                                                                                  also know as
 AE41 5652       high byte first      high word first    "big endian"
 5652 AE41       high byte first      low word first
 41AE 5256       low byte first      high word first
 5256 41AE       low byte first      low word first     "little endian"

I would reccomend trying all 4 combinations in the Slave program

from mbusd.

Hi, there is no problem with receiving in slave app, but in slave Energy Metter, and it's not possible to switch this setting in it.

from mbusd.

@3cky

I made a fix, and tested it. It seems to be working but I am not a modbus expert so I think you should review it critcially.

I made the following assumptions.

1. modbus length header only applies to TCP connections.
2. If the header length matches the actual length of what was received it leaves it alone. If not it changes the value to the calculated length before any further processing.
3. The implementation is only for Modbus Master on the TCP side and Slave on the tty side. Therefore only requests (TCP -> tty) need to be intercepted and validated.

from mbusd.

@sgel83 I've pushed some fixes into master, please update and test.

from mbusd.

My problem is another one, so I open new issue 33

from mbusd.