modbus tcp - mismatched addresses server/client

[GoogleCodeExporter]

What steps will reproduce the problem?
1.

using async server example but with with hr = ModbusSequentialDataBlock(0, [15, 
16, 21, 23]),

2.using sync client example with 

rr = client.read_holding_registers(0, 3)
print rr.registers

3. output is

[16, 21, 23]

Should this not be [15,16,21].  

version is 0.9.0 (linux)

Original issue reported on code.google.com by kilooc...@gmail.com on 29 May 2012 at 4:29

[GoogleCodeExporter]

In section 4.4 of the specification it states:

"""
The MODBUS application protocol defines precisely PDU addressing rules. In a 
MODBUS PDU each data is addressed from 0 to 65535. It also defines clearly a 
MODBUS data model composed of 4 blocks that comprises several elements numbered 
from 1 to n. In the MODBUS data Model each element within a data block is 
numbered from 1 to n.
"""

I used to map request(0) to address(0), however, I had multiple clients 
complaining that it violated the spec, so I changed it.  The fix of course is 
to simply start your data block addressing at 1 instead of 0.

Original comment by Bashw...@gmail.com on 29 May 2012 at 7:25

• Changed state: WontFix

[GoogleCodeExporter]

I had already done as suggested to get around the issue :)

Your API documentation clearly uses the term "address" in the datastore and not 
"element" so by definition this implies equivalence. 

eg your server example code

store = ModbusSlaveContext(
    di = ModbusSequentialDataBlock(0, [17]*100),
    co = ModbusSequentialDataBlock(0, [17]*100),
    hr = ModbusSequentialDataBlock(0, [17]*100),
    ir = ModbusSequentialDataBlock(0, [17]*100))

clearly starts with address 0 not 1, re-enforcing the implication that we are 
dealing in address space and not element space.

I would humbly suggest that examples and documentation differentiate these 
better. Perhaps the use "element" for 1...N space and "address" for 0...(N-1) 
space would clarify. This may prevent others falling over the same issue.

Original comment by kilooc...@gmail.com on 1 Jun 2012 at 11:45

[GoogleCodeExporter]

You are correct, I should make this more clear.  I will update the 
documentation and the examples to reflect this.

Original comment by Bashw...@gmail.com on 2 Jun 2012 at 12:19

• Changed state: Started

[GoogleCodeExporter]

Appreciate the rapid feedback.

The library is working great for me, so I am most happy.

Regards

Tarek

Original comment by kilooc...@gmail.com on 2 Jun 2012 at 5:46

[GoogleCodeExporter]

Original comment by Bashw...@gmail.com on 19 Jun 2013 at 1:47

• Changed state: Done