What's the reason for getting the result for the second try in ModbusTcp reading?












0















Sometimes I get an error response immediately when I read from a Modbus device at the first time, but when I try again this responded as the expected result.



This is the error message at first time:




pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)




Here's the simplified snippet code in iPython console:



In [1]: from pymodbus.client.sync import ModbusTcpClient
In [2]: cli = ModbusTcpClient('192.168.1.152', port=502)
In [3]: cli.connect()
Out[3]: True
In [4]: req = cli.read_holding_registers(0x1e, 2, unit=21) # First try.
In [5]: req.isError()
Out[5]: True
In [6]: req
Out[6]: pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)
In [7]: req = cli.read_holding_registers(0x1e, 2, unit=21) # Second try.
In [8]: req.isError()
Out[8]: False
In [9]: req.registers # As expected.
Out[9]: [16091, 15697]




What's the reason?





[UPDATE]:



I activate the Modbus slave/server logging:



import logging
from pymodbus.client.sync import ModbusTcpClient as ModbusClient

logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

client = ModbusClient('192.168.1.152', port=502)
client.connect()

print('First Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

print('Second Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

client.close()


Out:



First Try: 
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received))
DEBUG:pymodbus.framer.socket_framer:Processing:
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = True
Second Try:
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 2
DEBUG:pymodbus.transaction:SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.factory:Factory Response[ReadHoldingRegistersResponse: 3]
DEBUG:pymodbus.transaction:Adding transaction 2
DEBUG:pymodbus.transaction:Getting transaction 2
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = False


As you can see, in first try I got an error but in second try I got a good result.










share|improve this question

























  • It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

    – Sanju
    Nov 21 '18 at 2:33











  • @Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

    – Benyamin Jafari
    Nov 21 '18 at 19:58











  • I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

    – Sanju
    Nov 22 '18 at 6:05











  • @Sanju ok I will check it.

    – Benyamin Jafari
    Nov 22 '18 at 6:06











  • @Sanju I updated my answer with the Modbus slave logging.

    – Benyamin Jafari
    Nov 26 '18 at 5:53
















0















Sometimes I get an error response immediately when I read from a Modbus device at the first time, but when I try again this responded as the expected result.



This is the error message at first time:




pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)




Here's the simplified snippet code in iPython console:



In [1]: from pymodbus.client.sync import ModbusTcpClient
In [2]: cli = ModbusTcpClient('192.168.1.152', port=502)
In [3]: cli.connect()
Out[3]: True
In [4]: req = cli.read_holding_registers(0x1e, 2, unit=21) # First try.
In [5]: req.isError()
Out[5]: True
In [6]: req
Out[6]: pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)
In [7]: req = cli.read_holding_registers(0x1e, 2, unit=21) # Second try.
In [8]: req.isError()
Out[8]: False
In [9]: req.registers # As expected.
Out[9]: [16091, 15697]




What's the reason?





[UPDATE]:



I activate the Modbus slave/server logging:



import logging
from pymodbus.client.sync import ModbusTcpClient as ModbusClient

logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

client = ModbusClient('192.168.1.152', port=502)
client.connect()

print('First Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

print('Second Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

client.close()


Out:



First Try: 
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received))
DEBUG:pymodbus.framer.socket_framer:Processing:
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = True
Second Try:
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 2
DEBUG:pymodbus.transaction:SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.factory:Factory Response[ReadHoldingRegistersResponse: 3]
DEBUG:pymodbus.transaction:Adding transaction 2
DEBUG:pymodbus.transaction:Getting transaction 2
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = False


As you can see, in first try I got an error but in second try I got a good result.










share|improve this question

























  • It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

    – Sanju
    Nov 21 '18 at 2:33











  • @Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

    – Benyamin Jafari
    Nov 21 '18 at 19:58











  • I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

    – Sanju
    Nov 22 '18 at 6:05











  • @Sanju ok I will check it.

    – Benyamin Jafari
    Nov 22 '18 at 6:06











  • @Sanju I updated my answer with the Modbus slave logging.

    – Benyamin Jafari
    Nov 26 '18 at 5:53














0












0








0


0






Sometimes I get an error response immediately when I read from a Modbus device at the first time, but when I try again this responded as the expected result.



This is the error message at first time:




pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)




Here's the simplified snippet code in iPython console:



In [1]: from pymodbus.client.sync import ModbusTcpClient
In [2]: cli = ModbusTcpClient('192.168.1.152', port=502)
In [3]: cli.connect()
Out[3]: True
In [4]: req = cli.read_holding_registers(0x1e, 2, unit=21) # First try.
In [5]: req.isError()
Out[5]: True
In [6]: req
Out[6]: pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)
In [7]: req = cli.read_holding_registers(0x1e, 2, unit=21) # Second try.
In [8]: req.isError()
Out[8]: False
In [9]: req.registers # As expected.
Out[9]: [16091, 15697]




What's the reason?





[UPDATE]:



I activate the Modbus slave/server logging:



import logging
from pymodbus.client.sync import ModbusTcpClient as ModbusClient

logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

client = ModbusClient('192.168.1.152', port=502)
client.connect()

print('First Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

print('Second Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

client.close()


Out:



First Try: 
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received))
DEBUG:pymodbus.framer.socket_framer:Processing:
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = True
Second Try:
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 2
DEBUG:pymodbus.transaction:SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.factory:Factory Response[ReadHoldingRegistersResponse: 3]
DEBUG:pymodbus.transaction:Adding transaction 2
DEBUG:pymodbus.transaction:Getting transaction 2
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = False


As you can see, in first try I got an error but in second try I got a good result.










share|improve this question
















Sometimes I get an error response immediately when I read from a Modbus device at the first time, but when I try again this responded as the expected result.



This is the error message at first time:




pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)




Here's the simplified snippet code in iPython console:



In [1]: from pymodbus.client.sync import ModbusTcpClient
In [2]: cli = ModbusTcpClient('192.168.1.152', port=502)
In [3]: cli.connect()
Out[3]: True
In [4]: req = cli.read_holding_registers(0x1e, 2, unit=21) # First try.
In [5]: req.isError()
Out[5]: True
In [6]: req
Out[6]: pymodbus.exceptions.ModbusIOException(pymodbus.exceptions.InvalidMessageReceivedException('Incomplete message received, expected at least 8 bytes (0 received)'), 3)
In [7]: req = cli.read_holding_registers(0x1e, 2, unit=21) # Second try.
In [8]: req.isError()
Out[8]: False
In [9]: req.registers # As expected.
Out[9]: [16091, 15697]




What's the reason?





[UPDATE]:



I activate the Modbus slave/server logging:



import logging
from pymodbus.client.sync import ModbusTcpClient as ModbusClient

logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

client = ModbusClient('192.168.1.152', port=502)
client.connect()

print('First Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

print('Second Try: ')
res = client.read_holding_registers(0x1e, 2, unit=21)
print('isError = {}'.format(res.isError()))

client.close()


Out:



First Try: 
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x0 0x1 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 8 bytes (0 received))
DEBUG:pymodbus.framer.socket_framer:Processing:
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = True
Second Try:
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 2
DEBUG:pymodbus.transaction:SEND: 0x0 0x2 0x0 0x0 0x0 0x6 0x15 0x3 0x0 0x1e 0x0 0x2
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0 0x2 0x0 0x0 0x0 0x7 0x15 0x3 0x4 0x3f 0x99 0x8 0xe8
DEBUG:pymodbus.factory:Factory Response[ReadHoldingRegistersResponse: 3]
DEBUG:pymodbus.transaction:Adding transaction 2
DEBUG:pymodbus.transaction:Getting transaction 2
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
isError = False


As you can see, in first try I got an error but in second try I got a good result.







python modbus pymodbus






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 29 '18 at 7:04







Benyamin Jafari

















asked Nov 20 '18 at 9:33









Benyamin JafariBenyamin Jafari

2,88632038




2,88632038













  • It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

    – Sanju
    Nov 21 '18 at 2:33











  • @Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

    – Benyamin Jafari
    Nov 21 '18 at 19:58











  • I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

    – Sanju
    Nov 22 '18 at 6:05











  • @Sanju ok I will check it.

    – Benyamin Jafari
    Nov 22 '18 at 6:06











  • @Sanju I updated my answer with the Modbus slave logging.

    – Benyamin Jafari
    Nov 26 '18 at 5:53



















  • It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

    – Sanju
    Nov 21 '18 at 2:33











  • @Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

    – Benyamin Jafari
    Nov 21 '18 at 19:58











  • I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

    – Sanju
    Nov 22 '18 at 6:05











  • @Sanju ok I will check it.

    – Benyamin Jafari
    Nov 22 '18 at 6:06











  • @Sanju I updated my answer with the Modbus slave logging.

    – Benyamin Jafari
    Nov 26 '18 at 5:53

















It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

– Sanju
Nov 21 '18 at 2:33





It could be that your slave is slow to process the incoming requests. You can also set read timeout on your client and see if that helps. Some logs would be helpful to analyze.

– Sanju
Nov 21 '18 at 2:33













@Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

– Benyamin Jafari
Nov 21 '18 at 19:58





@Sanju The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error. The error log in the above code has been shown.

– Benyamin Jafari
Nov 21 '18 at 19:58













I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

– Sanju
Nov 22 '18 at 6:05





I mean the transaction logs not just the error message and does this happen with all the slaves or just one model of slave you are having?

– Sanju
Nov 22 '18 at 6:05













@Sanju ok I will check it.

– Benyamin Jafari
Nov 22 '18 at 6:06





@Sanju ok I will check it.

– Benyamin Jafari
Nov 22 '18 at 6:06













@Sanju I updated my answer with the Modbus slave logging.

– Benyamin Jafari
Nov 26 '18 at 5:53





@Sanju I updated my answer with the Modbus slave logging.

– Benyamin Jafari
Nov 26 '18 at 5:53












1 Answer
1






active

oldest

votes


















0














I had the same issue on a Keba heatpump controller. As mentioned by other, my problem was solved by increasing the timeout to 10 seconds, in your example by



client = ModbusClient('192.168.1.152', port=502, timeout=10)



10 seconds had for me some margin, I observed in wireshark always around 5 seconds. Starting from the second request, the responses always come easily within fractions of a second.



The reason given by my heatpump vendor was that the controller is short on memory and the modbus server is only started at the first incoming request for a connection.



@pymodbus developers: I suggest to increase the Default.timeout to 10 seconds.






share|improve this answer
























  • The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

    – Benyamin Jafari
    Nov 29 '18 at 7:05













  • That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

    – RDorsch
    Nov 30 '18 at 19:05













  • I test it with pymodbus 1.5.2 and 2.1.0 also.

    – Benyamin Jafari
    Nov 30 '18 at 19:20











  • Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

    – RDorsch
    Dec 1 '18 at 20:44











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389986%2fwhats-the-reason-for-getting-the-result-for-the-second-try-in-modbustcp-reading%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I had the same issue on a Keba heatpump controller. As mentioned by other, my problem was solved by increasing the timeout to 10 seconds, in your example by



client = ModbusClient('192.168.1.152', port=502, timeout=10)



10 seconds had for me some margin, I observed in wireshark always around 5 seconds. Starting from the second request, the responses always come easily within fractions of a second.



The reason given by my heatpump vendor was that the controller is short on memory and the modbus server is only started at the first incoming request for a connection.



@pymodbus developers: I suggest to increase the Default.timeout to 10 seconds.






share|improve this answer
























  • The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

    – Benyamin Jafari
    Nov 29 '18 at 7:05













  • That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

    – RDorsch
    Nov 30 '18 at 19:05













  • I test it with pymodbus 1.5.2 and 2.1.0 also.

    – Benyamin Jafari
    Nov 30 '18 at 19:20











  • Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

    – RDorsch
    Dec 1 '18 at 20:44
















0














I had the same issue on a Keba heatpump controller. As mentioned by other, my problem was solved by increasing the timeout to 10 seconds, in your example by



client = ModbusClient('192.168.1.152', port=502, timeout=10)



10 seconds had for me some margin, I observed in wireshark always around 5 seconds. Starting from the second request, the responses always come easily within fractions of a second.



The reason given by my heatpump vendor was that the controller is short on memory and the modbus server is only started at the first incoming request for a connection.



@pymodbus developers: I suggest to increase the Default.timeout to 10 seconds.






share|improve this answer
























  • The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

    – Benyamin Jafari
    Nov 29 '18 at 7:05













  • That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

    – RDorsch
    Nov 30 '18 at 19:05













  • I test it with pymodbus 1.5.2 and 2.1.0 also.

    – Benyamin Jafari
    Nov 30 '18 at 19:20











  • Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

    – RDorsch
    Dec 1 '18 at 20:44














0












0








0







I had the same issue on a Keba heatpump controller. As mentioned by other, my problem was solved by increasing the timeout to 10 seconds, in your example by



client = ModbusClient('192.168.1.152', port=502, timeout=10)



10 seconds had for me some margin, I observed in wireshark always around 5 seconds. Starting from the second request, the responses always come easily within fractions of a second.



The reason given by my heatpump vendor was that the controller is short on memory and the modbus server is only started at the first incoming request for a connection.



@pymodbus developers: I suggest to increase the Default.timeout to 10 seconds.






share|improve this answer













I had the same issue on a Keba heatpump controller. As mentioned by other, my problem was solved by increasing the timeout to 10 seconds, in your example by



client = ModbusClient('192.168.1.152', port=502, timeout=10)



10 seconds had for me some margin, I observed in wireshark always around 5 seconds. Starting from the second request, the responses always come easily within fractions of a second.



The reason given by my heatpump vendor was that the controller is short on memory and the modbus server is only started at the first incoming request for a connection.



@pymodbus developers: I suggest to increase the Default.timeout to 10 seconds.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 28 '18 at 22:13









RDorschRDorsch

11




11













  • The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

    – Benyamin Jafari
    Nov 29 '18 at 7:05













  • That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

    – RDorsch
    Nov 30 '18 at 19:05













  • I test it with pymodbus 1.5.2 and 2.1.0 also.

    – Benyamin Jafari
    Nov 30 '18 at 19:20











  • Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

    – RDorsch
    Dec 1 '18 at 20:44



















  • The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

    – Benyamin Jafari
    Nov 29 '18 at 7:05













  • That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

    – RDorsch
    Nov 30 '18 at 19:05













  • I test it with pymodbus 1.5.2 and 2.1.0 also.

    – Benyamin Jafari
    Nov 30 '18 at 19:20











  • Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

    – RDorsch
    Dec 1 '18 at 20:44

















The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

– Benyamin Jafari
Nov 29 '18 at 7:05







The timeout is set to 3 sec as default, but at the first try, it doesn't wait for the timeout, and immediately throw a result that has an error even with the timout=10 produce exactly the same result. But in the second try, I haven't any problem.

– Benyamin Jafari
Nov 29 '18 at 7:05















That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

– RDorsch
Nov 30 '18 at 19:05







That is clearly different from what I see here. With 3 seconds timeout, my first request always fails, with 10 seconds they pass. This applies both to pymodbus 2.1.0 and 1.5.2. Are you using an outdated version of pymodbus?

– RDorsch
Nov 30 '18 at 19:05















I test it with pymodbus 1.5.2 and 2.1.0 also.

– Benyamin Jafari
Nov 30 '18 at 19:20





I test it with pymodbus 1.5.2 and 2.1.0 also.

– Benyamin Jafari
Nov 30 '18 at 19:20













Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

– RDorsch
Dec 1 '18 at 20:44





Weird, I am running out of ideas. Wireshark helped me to debug my problem. This might help you, in particular you should be able to see, when the response from the server arrives....

– RDorsch
Dec 1 '18 at 20:44


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389986%2fwhats-the-reason-for-getting-the-result-for-the-second-try-in-modbustcp-reading%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

MongoDB - Not Authorized To Execute Command

How to fix TextFormField cause rebuild widget in Flutter

in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith