Getting the start address in the reponse object?

[Doug Latornell]

If I read a block of holding registers with read_holding_registers(start_addr, count), is there any way of getting at start_addr in the response that the deferred callback gets to operate on?

I ask because it would make dealing with the 125 register limit per request a lot easier to handle. If I want to read a block of, say 150 holding registers, I can easily break that up into 2 calls to read_holding_registers() with appropriate arg values. But without having the start_addr attached to the response I can't tell which response starts at which address in the list returned by a DeferredList.

Would a patch for the execute method of ReadHoldingRegistersRequest that passes address through to ReadHoldingRegistersResponse be considered?

[Bashwork]

So that would work for the server implementation, however that would not be passed back to the client as the protocol has place to put that data (unless you create a new message type like ReadHoldingRegisterWithStartCountRequest).  As for the client, this would currently be a little gross to implement as you would have to do one of the following:

1. pass the request into the client decoder factory and then into the decode method of the response (which is a very large breaking change)

2. add logic on the common.py mixin (or some decorator on top of it) to take the response, check if it is the correct response and not an error, and add to the response the data you want from the request.

The quickest way I can think of getting this functionality for you is to monkey patch the execute on the client and have it store the request like:

   response.request = request

   # can get start address like: response.request.start_addr

   return response 

Let me know if you have any other ideas or if this isn't sufficient.

[Doug Latornell]

I had thought about the monkey patching option, though hadn't figured out where to inject the patch. Thanks for the pointer.

I like the idea of attaching the request object to the response object - more general than attaching an individual request attribute.

I think I'm beginning to understand the limitations imposed by the protocol and its message types.

With regard to option 2, is it necessary to check that the response is good, not an error, before attaching the request? Wouldn't having the request object available in the response object be valuable even in the event of an error? Perhaps this is more protocol limitation that I haven't grokked yet...

[Doug Latornell]

Actually, with https://github.com/bashwork/pymodbus/issues/9 fixed, I don't need this functionality because I no longer need to use a DeferredList and I can reliably pass the start address as an argument to the callback that handles the responses.