FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: Modbus over USB-Serial  (Read 895 times)

kzxela

  • Newbie
  • *
  • Posts: 1
    • View Profile
Modbus over USB-Serial
« on: December 10, 2019, 11:16:16 PM »

We are using the Modbus protocol over a USB-serial connector (ID 0x0856:0xac25) on Linux using the ftdi-sio driver using RS-485 bus. We are using libmodbus for Modbus communications over RS-485.

For our purposes, we need to be able to respond to broadcast messages (this breaks the Modbus standard, but we control all of the devices so it works for us, this is for figuring out what devices are out there on the bus).

Responding to broadcast messages over the RS-485 bus will lead to collisions which we mitigate by adding random timeouts for responses.
This works great for us, however, sometimes we notice this causes the link to stop working (won't respond to reads/writes), this behavior however is transient because if we just issue a retry read/write, it will work for us.

The question we have is that is there some internal mechanism in the ftdi-sio driver or the hardware that has some sort of timeout in response to collissions that will cause the link not to respond for an amount of time? We ensure the random sleep time never exceeds 1 second for us, and while we do respond to broadcast messages, we only do so for reads, for writes, we do not so there should be no collisions. However, we see that sometimes even broadcast writes with no response fails to even reach the device over serial.  We ensure that this is not a faulty link by doing a stress test of reads/writes over a few days but with no broadcast. If we introduce broadcast reads/writes, this transient behavior of not responding seem to occur randomly. Any ideas is greatly appreciated.
Logged