M
Would a MODBUS server device with some of the 'Registers' defined as being greater than 16 bits be useable? For example, could I document my device memory map as follows:<pre>
Register # Type Useage
30001 1 U16 Current (mA)
30002 2 U32 Run time (ms)
30003 1 U16 Event Count
30004 8 OSTR Correllation Table
30005 1 U16 Distance (mm)</pre>
Where the number in the # column indicates the length of the register (in 16 bit WORDs).
Scenario 1
----------
The Client still reads registers using the common interpretation of the standard functions. I.e.
Read 'Current' Input Register: 01H,04H,00H,00H,00H,01H,CAH,31H
Read 'Run Time' Input Register: 01H,04H,00H,01H,00H,02H,0BH,20H
Note that in the second read the Number of Registers to read is still 2, in this case the 'Number of Registers' field is being interpreted as the expected data length in WORDs. The issue here is that the Client would be restricted to reading only one data object at a time.
Scenario 2
----------
A further extension of my stretching of the specification would be to interpret the 'Number of Registers' field to be exactly that, in which case multiple objects could be read at a time, but the length of the returned data would not always be exactly double the Number of Registers' requested. The Client would need to know the size of each 'Register' (of course, it already does or it wouldn't be able to unpack standard multi-register reads) to unpack the returned data.
Summary
-------
The specification is open to interpretation in many areas, with lots of manufacturers putting their own spin on how their devices implement it. If my product implements one or both of the proposed 'interpretations' above, would existing Clients (such as PLCs or OPC servers) be able to handle it or is it more likely to make people reject the product as being utterly incompatible?
Register # Type Useage
30001 1 U16 Current (mA)
30002 2 U32 Run time (ms)
30003 1 U16 Event Count
30004 8 OSTR Correllation Table
30005 1 U16 Distance (mm)</pre>
Where the number in the # column indicates the length of the register (in 16 bit WORDs).
Scenario 1
----------
The Client still reads registers using the common interpretation of the standard functions. I.e.
Read 'Current' Input Register: 01H,04H,00H,00H,00H,01H,CAH,31H
Read 'Run Time' Input Register: 01H,04H,00H,01H,00H,02H,0BH,20H
Note that in the second read the Number of Registers to read is still 2, in this case the 'Number of Registers' field is being interpreted as the expected data length in WORDs. The issue here is that the Client would be restricted to reading only one data object at a time.
Scenario 2
----------
A further extension of my stretching of the specification would be to interpret the 'Number of Registers' field to be exactly that, in which case multiple objects could be read at a time, but the length of the returned data would not always be exactly double the Number of Registers' requested. The Client would need to know the size of each 'Register' (of course, it already does or it wouldn't be able to unpack standard multi-register reads) to unpack the returned data.
Summary
-------
The specification is open to interpretation in many areas, with lots of manufacturers putting their own spin on how their devices implement it. If my product implements one or both of the proposed 'interpretations' above, would existing Clients (such as PLCs or OPC servers) be able to handle it or is it more likely to make people reject the product as being utterly incompatible?