Issue in making GUI responsive
-
@Asperamanca : Actually i have to keep my serialrequest synchronous.
@Kira what part of it, and why?
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. -
@J.Hilk : Ok i understand what @Asperamanca is trying to explain. Actually as per the requirement i have to give signal to the controller to move and capture the images at that location and repeat the operation n number of times. I am performing this operation in main thread which is causing main thread to freeze until the controller moves to the location.
Using the below codes:serialPort->write(serialCommand.toUtf8()); serialPort->waitForReadyRead(); //qDebug()<<"Bytes arrived"<<serialPort->bytesAvailable(); readData = serialPort->readAll();@J-Hilk : are you suggesting to create a thread which serves the serialrequest to avoid freezing of the mainthread and get the acknowledgement via signal slot mechanism from the thread.
As per my current experience with the program it is not feasible to create separate thread as it is called multiple times as it causes a lot of overhead. -
@J.Hilk : Ok i understand what @Asperamanca is trying to explain. Actually as per the requirement i have to give signal to the controller to move and capture the images at that location and repeat the operation n number of times. I am performing this operation in main thread which is causing main thread to freeze until the controller moves to the location.
Using the below codes:serialPort->write(serialCommand.toUtf8()); serialPort->waitForReadyRead(); //qDebug()<<"Bytes arrived"<<serialPort->bytesAvailable(); readData = serialPort->readAll();@J-Hilk : are you suggesting to create a thread which serves the serialrequest to avoid freezing of the mainthread and get the acknowledgement via signal slot mechanism from the thread.
As per my current experience with the program it is not feasible to create separate thread as it is called multiple times as it causes a lot of overhead.@Kira said in Issue in making GUI responsive:
serialPort->waitForReadyRead();
You're calling this in main thread?!
Why don't you use the asynchronous nature of QSerialPort instead? -
@J.Hilk : Ok i understand what @Asperamanca is trying to explain. Actually as per the requirement i have to give signal to the controller to move and capture the images at that location and repeat the operation n number of times. I am performing this operation in main thread which is causing main thread to freeze until the controller moves to the location.
Using the below codes:serialPort->write(serialCommand.toUtf8()); serialPort->waitForReadyRead(); //qDebug()<<"Bytes arrived"<<serialPort->bytesAvailable(); readData = serialPort->readAll();@J-Hilk : are you suggesting to create a thread which serves the serialrequest to avoid freezing of the mainthread and get the acknowledgement via signal slot mechanism from the thread.
As per my current experience with the program it is not feasible to create separate thread as it is called multiple times as it causes a lot of overhead.@Kira
The idea is to create 1 additional thread, probably during application start up.In that your Serialport lives, sending and receiving data and sitting idle when nothing is to be done.
Creating a new thread and serialport instance each time you want send/receive data has indeed way too much overhead.
I assume you get a message back, when your controller finished moving? You can react to that via a Signal that you emit, to your main thread
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. -
@Kira
The idea is to create 1 additional thread, probably during application start up.In that your Serialport lives, sending and receiving data and sitting idle when nothing is to be done.
Creating a new thread and serialport instance each time you want send/receive data has indeed way too much overhead.
I assume you get a message back, when your controller finished moving? You can react to that via a Signal that you emit, to your main thread
@J.Hilk said in Issue in making GUI responsive:
I assume you get a message back, when your controller finished moving? You can react to that via a Signal that you emit, to your main thread
Ok so this is the approach i should follow?
@jsulm said in Issue in making GUI responsive:
Why don't you use the asynchronous nature of QSerialPort instead?
@jsulm : I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
-
@J.Hilk said in Issue in making GUI responsive:
I assume you get a message back, when your controller finished moving? You can react to that via a Signal that you emit, to your main thread
Ok so this is the approach i should follow?
@jsulm said in Issue in making GUI responsive:
Why don't you use the asynchronous nature of QSerialPort instead?
@jsulm : I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
@Kira said in Issue in making GUI responsive:
I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
Sounds like something is wrong then - I doubt moving QSerialPort to another thread will change this behaviour.
-
@J.Hilk said in Issue in making GUI responsive:
I assume you get a message back, when your controller finished moving? You can react to that via a Signal that you emit, to your main thread
Ok so this is the approach i should follow?
@jsulm said in Issue in making GUI responsive:
Why don't you use the asynchronous nature of QSerialPort instead?
@jsulm : I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
@Kira said in Issue in making GUI responsive:
Ok so this is the approach i should follow?
Imho, yes
I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
Seems to me like you're missing a proper queue implementation on your SerialPort communication.
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. -
@Kira said in Issue in making GUI responsive:
Ok so this is the approach i should follow?
Imho, yes
I have tried that initially but it's not that effective? Basically there are so many request and response that sometimes i don't get response and s.ometimes previous and current responses together which is not feasible
Seems to me like you're missing a proper queue implementation on your SerialPort communication.
@J.Hilk said in Issue in making GUI responsive:
Seems to me like you're missing a proper queue implementation on your SerialPort communication.
@J-Hilk : I have tried multiple example also with the sample examples that comes with the qt creator. I was having problem with the microcontroller version which i was using.
As per what i have understood about signal slot mechanism is that if the slot is not executed at given instance of time it get queued. So their arise a possiblity of the slots getting queue and be the reason of my delay in response creating a bottleneck between the sender and the receiver.
-
@J.Hilk said in Issue in making GUI responsive:
Seems to me like you're missing a proper queue implementation on your SerialPort communication.
@J-Hilk : I have tried multiple example also with the sample examples that comes with the qt creator. I was having problem with the microcontroller version which i was using.
As per what i have understood about signal slot mechanism is that if the slot is not executed at given instance of time it get queued. So their arise a possiblity of the slots getting queue and be the reason of my delay in response creating a bottleneck between the sender and the receiver.
@Kira A signal is only queued when communicating between different threads (or setting queued connection type explicitly). In same thread emitting a signal means that all connected slots will be called immediately one after another (in same order as connect() calls), so no queueing.
-
@Kira A signal is only queued when communicating between different threads (or setting queued connection type explicitly). In same thread emitting a signal means that all connected slots will be called immediately one after another (in same order as connect() calls), so no queueing.
@jsulm : @J-Hilk : Guys thanks to you did some sample program regarding implementation of QSerialPort and found an interesting example listed under qt creator.
https://doc.qt.io/qt-5/qtserialport-blockingmaster-example.html
Here they have clearly mentioned the example of using serialPort in gui mode.
Just i have one doubt:
=>Here every time port is being set, i don't have any such condition in my example so can just set port once in the thread ?
=>Also does QWaitCondition have any extra overhead ?
=>Can i implement the similar logic for my camera thread where the thread runs continuously without any sleep? -
@jsulm : @J-Hilk : Guys thanks to you did some sample program regarding implementation of QSerialPort and found an interesting example listed under qt creator.
https://doc.qt.io/qt-5/qtserialport-blockingmaster-example.html
Here they have clearly mentioned the example of using serialPort in gui mode.
Just i have one doubt:
=>Here every time port is being set, i don't have any such condition in my example so can just set port once in the thread ?
=>Also does QWaitCondition have any extra overhead ?
=>Can i implement the similar logic for my camera thread where the thread runs continuously without any sleep?@Kira That example shows how to use SYNCHRONOUS API in GUI thread. But why do you want to use synchronous API instead of the asynchronous? If there is no valid reason to use synchronous API use the asynchronous - this is WAY easier compared to dealing with threads.
-
@jsulm : @J-Hilk : Guys thanks to you did some sample program regarding implementation of QSerialPort and found an interesting example listed under qt creator.
https://doc.qt.io/qt-5/qtserialport-blockingmaster-example.html
Here they have clearly mentioned the example of using serialPort in gui mode.
Just i have one doubt:
=>Here every time port is being set, i don't have any such condition in my example so can just set port once in the thread ?
=>Also does QWaitCondition have any extra overhead ?
=>Can i implement the similar logic for my camera thread where the thread runs continuously without any sleep?@Kira and just to add to @jsulm:
I doubt the serial port handling is your problem. Serial ports are slow and handling them with signals and slots is most often no problem.
I think your problem is handling the data you received through serial port. If that takes a bit longer, you'll block your GUI.
Regards
-
@Kira That example shows how to use SYNCHRONOUS API in GUI thread. But why do you want to use synchronous API instead of the asynchronous? If there is no valid reason to use synchronous API use the asynchronous - this is WAY easier compared to dealing with threads.
@jsulm said in Issue in making GUI responsive:
That example shows how to use SYNCHRONOUS API in GUI thread.
Will this approach cause my GUI to hang if i don't get a timely response??
Can you please suggest how can i implement the following requirement using asynchronous approch?
->Send serial data
->Read the data
->If data read successfully than allow another serial request. -
@Kira and just to add to @jsulm:
I doubt the serial port handling is your problem. Serial ports are slow and handling them with signals and slots is most often no problem.
I think your problem is handling the data you received through serial port. If that takes a bit longer, you'll block your GUI.
Regards
@aha_1980 said in Issue in making GUI responsive:
I think your problem is handling the data you received through serial port. If that takes a bit longer, you'll block your GUI.
I have used the standard example to get data from the serial port. Still sometimes i don't get response on my serialPort.
Will look again into the issue and see to it that the data handling is done properly.If the above asynchronous approach will cause my GUI to hang i will have to use the second appoach.
-
@jsulm said in Issue in making GUI responsive:
That example shows how to use SYNCHRONOUS API in GUI thread.
Will this approach cause my GUI to hang if i don't get a timely response??
Can you please suggest how can i implement the following requirement using asynchronous approch?
->Send serial data
->Read the data
->If data read successfully than allow another serial request.@Kira said in Issue in making GUI responsive:
Will this approach cause my GUI to hang if i don't get a timely response??
Not in that example. But again: why not simply use asynchronous API? Why do you make things unnecessary complex?
-
@Kira said in Issue in making GUI responsive:
Will this approach cause my GUI to hang if i don't get a timely response??
Not in that example. But again: why not simply use asynchronous API? Why do you make things unnecessary complex?
@jsulm said in Issue in making GUI responsive:
Not in that example. But again: why not simply use asynchronous API? Why do you make things unnecessary complex?
@jsulm : Actually i am writing program for system which is completely based on feedback mechanism.
As an example: If i give the my device command to move 15 steps in an axis i will have wait for feedback from my controller device after than i can allow user to give next command.
Feedback is generated by after the device have moved. It is also observed that if i continuously request the device without getting the feedback, serial port hangs most of the time.For different command there are different feedback. I will have to analyse the feedback generated
and allow for controller to move.If the feedback mechanism can be implemented in asynchronous approch i would be happy to implement.Can you please help with an example if already available?
I have checked the terminal example in qt creator but it does not have feedback mechanism -
@jsulm said in Issue in making GUI responsive:
Not in that example. But again: why not simply use asynchronous API? Why do you make things unnecessary complex?
@jsulm : Actually i am writing program for system which is completely based on feedback mechanism.
As an example: If i give the my device command to move 15 steps in an axis i will have wait for feedback from my controller device after than i can allow user to give next command.
Feedback is generated by after the device have moved. It is also observed that if i continuously request the device without getting the feedback, serial port hangs most of the time.For different command there are different feedback. I will have to analyse the feedback generated
and allow for controller to move.If the feedback mechanism can be implemented in asynchronous approch i would be happy to implement.Can you please help with an example if already available?
I have checked the terminal example in qt creator but it does not have feedback mechanism@Kira You can take a look at this: https://doc.qt.io/qt-5/qstatemachine.html
-
@Kira You can take a look at this: https://doc.qt.io/qt-5/qstatemachine.html
@jsulm said in Issue in making GUI responsive:
You can take a look at this: https://doc.qt.io/qt-5/qstatemachine.html
@jsulm : Hi, just a last clarfication. I went through the documentation of statemachine.
And i have following signal and slots:
connect(serial, &QSerialPort::readyRead, this, &MainWindow::readData);connect(console, &Console::getData, this, &MainWindow::writeData);
How can i apply the state machine logic to this
Thanks and regards -
The idea would be that you will drive the state machine based on the feedback your receive from the device.
One controller object that will send command and parse answers and will emit something that will allow the state machine to go to the next state.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
The idea would be that you will drive the state machine based on the feedback your receive from the device.
One controller object that will send command and parse answers and will emit something that will allow the state machine to go to the next state.
