Patch: Extended timeout handling in ModbusTransactionManager #150
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi bashwork,
Long time no chat, hope you're well. I'm finally getting around to the PR you and I discussed last June.
Problem statement is, we're using ModbusSerialClient to talk to a solar inverter that responds to write holding registers requests with about a 1s delay. Using current pymodbus code, I either need to use a timeout >>1 s, or the FIFOTransactionManager will catch the inverter's response after returning from read_holding_registers. If I use a long timeout, the call to
self.client._recv(1024)will take the entire timeout to return; if not, I end up with a log file like this one. Note that at 2017-01-30 14:50:28,723 I submit a WriteHoldingRegistersRequest and its response is returned for the next call to read_holding_registers.The truly correct way to handle this, as you mention in your comment in
ModbusTransactionManager.execute(), would be to calculate the number of bytes we expect the response to contain, and callself.client._recv(num_bytes)instead ofself.client._recv(1024). That way we could both use a long socket timeout and avoid blocking for the whole timeout when a valid response is received.I've been waiting to PR until I found time to implement that response length prediction. But I've been busy and it'd be some actual work... and I just haven't gotten to it.
Until then, would you accept this patch? I've reduced the serial socket's timeout and added a loop to poll it multiple times, handling the slow response while not affecting normal behavior.