[Feature Request]: Reading blocks of registers

[nielsbasjes]

What would you like to happen?

As requested by @chrisdutz a wireshark dump when requesting a set of correctly and incorrectly alligned sets of modbus registers.

Notes about this trace:

• The device at hand is a solar inverter that conforms to the SunSpec standard.
• The requested field is this one (which apparently must be read completely): https://github.com/sunspec/models/blob/master/json/model_1.json#L36

            {
                "desc": "Manufacturer specific value (32 chars)",
                "label": "Model",
                "mandatory": "M",
                "name": "Md",
                "size": 16,
                "static": "S",
                "type": "string"
            }

• I have the device in an isolated network so I do an SSH with port forwarding to a jumphost. The effect is that all traffic is to and from localhost (127.0.0.1) and the port TOWARDS the system is port 1502 (instead of the normal 502).
• The connection definition is modbus-tcp:tcp://127.0.0.1:1502?unit-identifier=126

In sequence in a single request I retrieve it:

• Correctly.
• Correct start address yet I get 15 instead of 16 registers.
• Start reading at the second register till the end.

The console output related to this trace:

17:15:44,366 [INFO ] TcpChannelFactory                       :   60: Configuring Bootstrap with ModbusTcpConfiguration{requestTimeout=5000, unitIdentifier=126}
17:15:44,632 [INFO ] PartialRegisters                        :   65: Good ModbusTag[4x40021:UINT[16]]:  0x5342 0x332E 0x362D 0x3141 0x562D 0x3431 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
17:15:44,632 [ERROR] PartialRegisters                        :   68: FAIL ModbusTag[4x40021:UINT[15]]: INVALID_ADDRESS
17:15:44,633 [INFO ] PartialRegisters                        :   65: Good ModbusTag[4x40022:UINT[15]]:  0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF 0xFFFF

Programming Languages

• plc4j
• plc4go
• plc4c
• plc4net

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• CANopen
• DeltaV
• DF1
• EtherNet/IP
• Firmata
• KNXnet/IP
• Modbus
• OPC-UA
• S7

[nielsbasjes]

modbus-sunspec.zip

[chrisdutz]

Oh gee ... I think I must have completely dropped the ball on this ... looking at the date, I guess this was just the time everything at my last job wen't totally bananas ... sorry for not following up on this.

In the last few days I have worked a lot on the modbus drivers and they should be in quite a different state to when you opened this issue ... could you confim it's still an issue?

[nielsbasjes]

For me this is not seen as a bug in your library but as a peculiar response of a real life system.
Ill double check if your newer implementation changes anything (I expect it won't).

[nielsbasjes]

Also; I realized a while ago that the only way any library can reliable read this device is when this library has a full schema of the device at hand. Only by following the constraints imposed by this schema can the library do the modbus calls that result in correct data.

Note that the mentioned SunSpec has an even harder schema definition.
For example this field (they call it point) A (AC Current) has a scaling factor field A_SF which means that the value from the registers related to A must be multiplied by 10^the value of the field A_SF to get the actual value.

So to get the value of the field A you must read the registers related to A and A_SF before you can determine the actual value.

I have been experimenting for a few months now on how to get to a form of schema definition that allows for all of these variants. I'm still working on that.

So please just treat this as an FYI around the fact that some devices show unexpected behavior if you try to read valid registers in a way that does not meet their schema.

[nielsbasjes]

@chrisdutz This was the mail thread before I put this up. https://lists.apache.org/thread/pyzrwvv5gbrj1bgyx8hyr8k62rzywys8

[chrisdutz]

Just to be on the safe side ... I'm a bit unsure as to what needs to be done in this issue ... is this still valid?

[nielsbasjes]

From my perspective this is something I want. I have been working (as a side project) to write the code needed to make this happen.
It needs a way to define a schema (modbus calls this a mapping) that is much bigger than simply int or float.
The hard part is that this must also ensure any modbus actions stay within the limitations defined by the schema.

What needs to be done is a lot.
So much that I say it cannot be seen as a simple feature. It is a totally new functionality.

Right now I already have a partial prototype that works on my machine.

So I propose this issue is closed and I'll ping you when I have something that is good enough to show you.