QSerialport did not emit readyRead () signal，but USB monitor data received.Only occasionally problem
-
@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
Qt has to stay free or it will die.
-
@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
@aha_1980 @J-Hilk yeah,really, there was a problem still.Now, I start to suspect a problem with my code because I use
QSerialPortin 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 @J-Hilk yeah,really, there was a problem still.Now, I start to suspect a problem with my code because I use
QSerialPortin 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.@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
Qt has to stay free or it will die.
-
@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
-
@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 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
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
-
@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.
-
@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.
@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...
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@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...@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 @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.@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
-
@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.@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
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@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
