stephane / libmodbus

A Modbus library for Linux, Mac OS, FreeBSD and Windows
http://libmodbus.org
GNU Lesser General Public License v2.1
3.44k stars 1.75k forks source link

MODBUS RTU Error Connection Time Out: select #556

Closed Milav-teq closed 3 years ago

Milav-teq commented 4 years ago

Please read the following carefully before submitting this new issue.

When you get here and you are still convinced that you want report a bug:

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 ## Expected behaviour < i want to read input bit and input registers from the modbus master application.> ## Actual behaviour ## libmodbus output with debug mode enabled <...>
karlp commented 4 years ago

You could have

  • a/b switched
  • you don't have a connection between the devices,
  • the other device isn't listening to the read bit command

Do other functions work? have you ever used this device before with any other software?

adgnaf commented 3 years ago

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)
adgnaf commented 3 years ago

Finally I resolved this issue in my case by

  • replace default rts function with custom rts function.
  • comment out receive mode change.
dominikfigueroa commented 3 years ago

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?

dominikfigueroa commented 3 years ago

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.

karlp commented 3 years ago

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.

watsocd commented 3 years ago

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:

  1. Cable type and quality.
  2. Cable length.
  3. Termination workmanship.
  4. Termination resistor locations.
  5. Number and types of devices on the wire.

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

stephane commented 3 years ago

Thank you again @karlp for your help.

spark-fire commented 1 year ago

@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.