I just noticed there is a new Firmware out RUT9_R_00.07.03.2
I decided to update the firmware...
II see that the modbus serial stuff has been completely reorganized into a far more logical and intuitive configuration
but I also see that it is just as disfunctional as before and actually shows the identical comm logs in modbus slave
I am using ModbusPoll as the reference implementation of competent serial modbus RTU comms
to simplify the scenario I have created a stripped down ModbusPoll environment consisting of only two variables
this is what the comm stream looks like:
Tx:000473-0B 03 1B 60 00 02 C2 5B
Rx:000474-0B 03 04 42 A0 88 FA A2 2A
Tx:000475-0B 03 1B 5E 00 02 A3 97
Rx:000476-0B 03 04 00 00 00 00 50 33
Tx:000477-0B 03 1B 60 00 02 C2 5B
Rx:000478-0B 03 04 42 A0 88 FA A2 2A
Tx:000479-0B 03 1B 5E 00 02 A3 97
Rx:000480-0B 03 04 00 00 00 00 50 33
When I connect ModbusSlave and monitor what the RUT955 emits:
Tx:007470-0B 03 01 C1 32
Rx:007471-0B 83 03 21 33
Tx:007472-0B 03 01 C1 32
Rx:007473-0B 83 03 21 33
Tx:007474-0B 03 01 C1 32
Rx:007475-0B 83 03 21 33
Tx:007476-0B 03 01 C1 32
Rx:007477-0B 83 03 21 33
If we analyze the MPB request : Tx:000473-0B 03 1B 60 00 02 C2 5B
0B is the ID (11)
03 is the Read Holding Register modbus transfer type
1B 60 is the address (7008)
I'm not positive what the 0 is
02 is the number of registers to transfer
C2 5B is the CRC
The request from the RUT 955 is a lame incomplete facsimile
Tx:007476-0B 03 01 C1 32
OB is the ID OK
03 is read holding Register OK
01 is what ? the First Register Numer and Register Count parameters appear to be ignored and discarded
C1 32 is the CRC OK
I notice that the error code is now processed and displayed, Thank you!
Request failed, result: Failed to get response: Illegal data address
Yeah, no sit sherlock, the data address is not merely illegal, it is totally missing