What's the reason for getting the result for the second try in ModbusTcp reading?
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
|
show 1 more comment
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
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
|
show 1 more comment
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
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
python modbus pymodbus
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
|
show 1 more comment
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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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.
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 thetimout=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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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 thetimout=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
add a comment |
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.
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 thetimout=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
add a comment |
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.
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.
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 thetimout=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
add a comment |
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 thetimout=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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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