RS485 Half Duplex Communication
-
In my honest opinion this is not a problem related to QSerialPort. The 485 bus uses the enable (sometimes called direction) signal to write or read from bus.
When that signal is not managed directly by the 485 transiver we normally write a kernel driver so, after that, everithing has to work perfecly.
I suggest you to check who and how is managing the enable signal.
After that some devices make an echo in the bus to manage the anticollision feature.
If you send something and after that you receive back the same row of bytes that means that none has disturbed the comminication. If you receive a byte row different from that you have trasmit, that meas that someone in the bus has disturb the communication so you have to resend. -
wrote on 27 May 2021, 05:44 last edited by
Hi, QSerialPort manages the rs485 interfaces as a normal full duplex interface. The enable (direction) signal must be manged by the transceiver or by a specific kernel driver.
-
@HSKW said in RS485 Half Duplex Communication:
Qt version used is 5.9.4
I didn't get what problem we can get by mixing ioctl and QSerialPort? And how we would be able to make same configuration as done using ioctl with QSerialPort.The problem is not the mixing but how your are doing it. You're opening the same file twice so there might things that might get lost in between. You should open it with QSerialPort and then use the handle that it provides to call your ioctl.
wrote on 4 Jun 2021, 14:54 last edited by HSKW 6 Apr 2021, 14:55@SGaist
Can you please let me know how to set RS485 mode with half duplex by opening with QserialPort and then using the handle for ioctl?Also, just an update on the issue:
- Yocto BSP with Kernel version 4.1.15, Qt version is 5.9.4
- It is observed that after exchanging some packets over RS485, even though Qt application is not sending or receiving anything, still on Docklight(connected to monitor serial communication) 4096 bytes of data (current byte sent - 4096) are seen.
- Looking at the signal over logic analyzer, we found that TX_ENABLE line remains high in such a case till these old 4096 bytes are dumped.
- We think that somehow kernel driver's TX buffer is getting corrupted and that is getting dumped, causing TX_ENABLE line to remain high.
Do we know if this as an known issue? Or is our application causing the TX buffer corruption - which we don't think, as we are clearing the buffer before sending data over SErialPort using clear() call and also calling flush() after sending data. Moreover, we always get bytesWritten signal indicating complete bytes written before we send next request.
any help is highly appreciated.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
wrote on 9 Jun 2021, 09:44 last edited by mrdebug 6 Sept 2021, 09:45
I don't know which is your problem but I assure QSerialPort works perfectly, since 5.9 release up to now because I use it in a lot of projects, with half (485) and full duplex interfaces, in Linux, Windows, Mac and imx devices.
You should search the problem somewehere.
If the behaviour happens only with QSerialPort still the problem is somewhere.
If you want to make a test using something else than Qt you could find interesting this:
https://github.com/denisgottardello/ComPortServer
A console based application to test the serial interface and to convert it in a tcp socket, based on fpc. You shouldn't have problem to use it in you device. -
wrote on 28 Dec 2023, 09:32 last edited by
HI
We too have the same problem
We use QT 5.7 and instead of using QSerialPort we use open() write() and read()
Usually the communication is correct, then suddenly part of the packet is resent or even the same packet many times, in short I have to send nine bytes and instead up to eighty bytes come out.
Did you have a solution for this problem?
Ciao, Beppe
-
wrote on 29 Dec 2023, 02:23 last edited by
Hi, perhaps you could work around the bug by stuffing the data inside packets with a sequence number? So when the same data is randomly retransmitted the receiver can safely discard it because it already has that packet.
-
Hi, perhaps you could work around the bug by stuffing the data inside packets with a sequence number? So when the same data is randomly retransmitted the receiver can safely discard it because it already has that packet.
wrote on 13 Jan 2024, 19:54 last edited byQtSerialPort can't resend the same packet automatically. Have the device or the 485 converter support anti collision? This problem sounds like an 485 anti collision behaviour.