Closed Milav-teq closed 3 years ago
You could have
Do other functions work? have you ever used this device before with any other software?
I met the same issue. This issue only affect RS485, not RS232. The following code always timeout modbus-rtu.c : _modbus_rtu_select
((s_rc = select(ctx->s+1, rset, NULL, NULL, tv)) == -1)
Finally I resolved this issue in my case by
Finally I resolved this issue in my case by
- replace default rts function with custom rts function.
- comment out receive mode change.
Hi! I'm having this exact same problem using RS485. It always times out at the ((s_rc = select(ctx->s+1, rset, NULL, NULL, tv)) == -1)
call.
Could you please elaborate a bit more on how you solved this? What is the "rts function" that you replaced? What did you replace it with?
What is "recieve mode change" that you commented out?
Finally I resolved this issue in my case by
- replace default rts function with custom rts function.
- comment out receive mode change.
Hi! I'm having this exact same problem using RS485. It always times out at the
((s_rc = select(ctx->s+1, rset, NULL, NULL, tv)) == -1)
call.Could you please elaborate a bit more on how you solved this? What is the "rts function" that you replaced? What did you replace it with?
What is "recieve mode change" that you commented out?
For anyone that stumbles upon this thread. I didn't really resolve my issue, I was simply forced to not call read_holding_registers
as often as I wanted to. I'm my case I wanted to read from a device every 250ms but I ran into the connection timeout error. When I read from the device every 500ms the connection never times out.
For anyone that stumbles upon this thread. I didn't really resolve my issue, I was simply forced to not call
read_holding_registers
as often as I wanted to. I'm my case I wanted to read from a device every 250ms but I ran into the connection timeout error. When I read from the device every 500ms the connection never times out.
And you may actually find that specified in the datasheet of the device you're querying. It's not at all uncommon. Sometimes you also need to have delays between messages.
As Karl states, network delays are partially dependent on the slave device and but also several other factors with dealing with RS-485 RTU based systems. Factors that can cause a system to work perfectly on the test table and fail miserably in the field.
All of the comments below have nothing to do with problems with libmodbus. These are all factors caused in the field that need to be handled in your code.
In our system, we call it the inter_request_delay_ms. This is the minimum delay in ms between master requests sent over the wire. It is normally set between 250 and 500ms.
This delay depends on the following other factors with no order of priority:
All of the above effect the network stability and speed. When you test your code at your desk with one slave device and the master with a short piece of brand-new cable between them, all you are proving is that your coding is good and how fast you can communicate under PERFECT conditions. Field conditions will often be slower.
Chuck Watson BS, CEM, CMVP
Direct USA 724-799-1529
From: Karl Palsson @.> Sent: Wednesday, March 24, 2021 8:57 AM To: stephane/libmodbus @.> Cc: Subscribed @.***> Subject: Re: [stephane/libmodbus] MODBUS RTU Error Connection Time Out: select (#556)
For anyone that stumbles upon this thread. I didn't really resolve my issue, I was simply forced to not call read_holding_registers as often as I wanted to. I'm my case I wanted to read from a device every 250ms but I ran into the connection timeout error. When I read from the device every 500ms the connection never times out.
And you may actually find that specified in the datasheet of the device you're querying. It's not at all uncommon. Sometimes you also need to have delays between messages.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stephane/libmodbus/issues/556#issuecomment-805797475 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFDSANLA2Z7VNSJBQ7L5LLTFHORTANCNFSM4PZU6I7A . https://github.com/notifications/beacon/AAFDSAO2E7MUBYTY6AHFKPDTFHORTA5CNFSM4PZU6I7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGADX4YY.gif
Thank you again @karlp for your help.
@adgnaf I have encountered the same problem. In the end, each read and write delay is 15ms, and reconnection occurs when a timeout occurs. This is acceptable to me.
Please read the following carefully before submitting this new issue.
Please ensure, that you are really reporting a bug. When in doubt, post a message on https://groups.google.com/forum/#!forum/libmodbus or send an email to libmodbus@googlegroups.com
Please do not open issues to ask questions about using libmodbus. Use the mailing list for this as there are many more people reading that list, who could help you.
When using libmodbus from a distribution (Debian, Fedora...), please report the bug first in the bug tracker of the distribution. The reason for doing so is that the package maintainer should have a chance to look at the issue first as it might be a packaging error. If/when the package maintainer comes to the conclusion that is really an upstream bug, then he/she will usually report it here by himself/herself. This is because he/she is interested in staying in the notification chain to decide about a backport as soon as a bugfix is available. Otherwise you (distribution user) will be asked to do so explicitely.
When you get here and you are still convinced that you want report a bug:
Use a clear and decriptive title for the issue to identify
Which version of libmodbus are you using? you can obtain this information from your package manager or by running
pkg-config --modversion libmodbus
. You can provide the sha1 of the commit if you have fetched the code withgit
.Which operating system are you using?
Describe the exact steps which reproduce the problem in as many details as possible. For example, the software/equipement which runs the Modbus server, how the clients are connected (TCP, RTU, ASCII) and the source code you are using.
Enable the debug mode, libmodbus provides a function to display the content of the Modbus messages and it's very convenient to analyze issues (http://libmodbus.org/docs/latest/modbus_set_debug.html).
Good bug reports provide right and quick fixes!
Finally, thank you very much for using libmodbus and taking the time to file a good bug report. Doing so signals your respect for the developers.
The following template helps you to address the points above. Please delete everything up to and including the following line which starts with ---.
libmodbus version
<libmodbus version 3.1.6>
OS and/or distribution
<Linux ELF 32-Bit LSB ARM,EABI5>
Environment
<16-bit Controller> ## Description