QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem

[Crawl.W]

I simply connect readyRead() with handle function. My USB monitor detect the received data,but the readyRead() did not trigger. And when I write serial port again, I receive the last respone at once.I know which is the last response, because I will receive a response later. I just record log after handle funcation. My Qt version is 5.11.1.

Application output as following:

11:22:12.001 GetAxisZPosition
11:22:13.490 GetAxisZPosition again
11:22:13.490 ReceiveAxisZPosition
11:22:13.491 SetAxisZMoveSpeed
11:22:13.494 ReceiveAxisZPosition

The second log show that I query X axis pos again because I estimate data lost.However, my USB monitor dectect the respone.

[J.Hilk]

@Crawl-W
please update your Qt version, in 5.12.4 & 5.12.5 and (I think) 5.13.0 & 1. QSerialport is broken, as in it emits not ready read signal

see
https://bugreports.qt.io/browse/QTBUG-78086

[Crawl.W]

@J-Hilk My version is 5.11.1 and trigger the problem occasionally .

[J.Hilk]

@Crawl-W
well, have you tried/can you try with 5.12.6 ?

[Crawl.W]

@J-Hilk thks, I try it soon.What's more painful is that it was an accidental event.

[aha_1980]

@Crawl-W said in QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem:

@J-Hilk thks, I try it soon.What's more painful is that it was an accidental event.

Well, it might still be a problem in your code. Can you show it?

Regards

[Crawl.W]

@aha_1980 @J-Hilk yeah,really, there was a problem still.Now, I start to suspect a problem with my code because I use QSerialPort in the GUI thread.
I found that if there is a slightly longer time interval（more than 3min）, the probability of problems is relatively high.But not necessarily.

[aha_1980]

@Crawl-W said in QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem:

Now, I start to suspect a problem with my code because I use QSerialPort in the GUI thread

There is nothing wrong with that. I do this all the time.

There is one problem on Windows though: when you click and hold the mouse button on the window's title bar, the window does not receive events anymore. So if the serial port is in the GUI thread, it will stuck until the mouse is released.

Regards

[Crawl.W]

@aha_1980 Okay, I will do some checks based on your reminder.Thks!

[Crawl.W]

@aha_1980 I see another question you answered https://forum.qt.io/topic/94537/qserialport-troubles-on-windows-10/3. My client slowed down also and cpu has been running. My countdown is running normally in the gui thread and highlight effect of minimize button a bit stuck. Just a word, I use QSerialPort in the GUI thread and the program, program always has only one thread, although it has been said before, it is too long. I will go to debug source code further, but if you know what's going on it would be great. The number of threads in this case is 21 which is show in Win10's task mannager.
OS : Windows 10 Pro
Kit : Qt 5.12.6 msvc2017 64bit
Cpu:7700k

[aha_1980]

Hi @Crawl-W,

no unfortunately I don't know what's going on.

And as you cannot share your code, it's just guessing from my side.

So the best tip I can give you: Minimize your program. Generate reproduciable test cases. Use tools like profilers or timestamp logging to find the places that eat your CPU.

Good luck, regards

[Crawl.W]

@aha_1980 I found QIODevice::readyRead eat my cpu, but I am still not know why. This usually happens in a pop-up dialog to let the user confirm an action and the user waits for a while to do it. The serial port was not actively disconnected during the period, and of course it was not reconnected, just continue to send command to the equipment. From the cpu curve, I suspect the effect of the timer.

[J.Hilk]

@Crawl-W said in QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem:

I found QIODevice::readyRead eat my cpu, but I am still not know why. This usually happens in a pop-up dialog to let the user confirm an action and the user waits for a while to do it.

No. Popup dialogs do not consume cpu. If your (Qt)program does, then you're doing something wrong. Most likely blocking while loops and manual event loop spinning or QEventLoop uses.
Stuff like that, and one isn't supposed to do...

[Crawl.W]

@aha_1980 @J-Hilk First of all, I need to clarify that the software I maintain now is really suck. I most likely have solved this problem and now the program runs well.

I need to describe the process of this problem:
1.QTextEdit becomes stuck slowly because of appending so many messages
2.a dialog pops up(exec()), after confirmation then update tableview viewport with QTableView::viewport()->update()
3.click a button continue to R/W serial port.

I originally suspected it was due to QTableView::viewport()->update(), which schedules a paint event for processing when Qt returns to the main event loop. However, my experiment found QTextEdit's stuck lead the QSerialport did not emit readyRead () signal.

Why?
thanks you guys for patience all the time.

[aha_1980]

@Crawl-W

However, my experiment found QTextEdit's stuck lead the QSerialport did not emit readyRead () signal.

I can only think of problems if both are in the same thread, and maybe the event loop does not run anymore when you edit gets too slow.

Anyway, glad you solved it!

Regards

[J.Hilk]

@Crawl-W said in QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem:

QTextEdit's

have you tried setting the undoRedo property to false ? That's usually a high performance eater when one appends (a lot) to the textedit

setUndoRedoEnabled(false);

the default is true

[Crawl.W]

@J-Hilk Tks, I will do a test. Btw, I want to know more the root cause of QSerialport did not emit readyRead () signal.