Can calling a slot too often lead to delays in data transfer?
-
wrote on 18 Nov 2020, 11:01 last edited by SpaceToonThis post is deleted!
-
@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
My problem is that for one device the data "arrive" and are displayed and plotted on the GUI with a delay but for the other device not
Are these different devices (I mean different hardware)?
The frequency of calling the slot shouldn't be a problem, but the time needed to execute the slot.Just a note - this is not the correct way to convert a QByteArray to a string:
newValue = newValue + (QString)value; -
@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
My problem is that for one device the data "arrive" and are displayed and plotted on the GUI with a delay but for the other device not
Are these different devices (I mean different hardware)?
The frequency of calling the slot shouldn't be a problem, but the time needed to execute the slot.Just a note - this is not the correct way to convert a QByteArray to a string:
newValue = newValue + (QString)value;wrote on 18 Nov 2020, 12:20 last edited by SpaceToon@jsulm Thank you! Yes these two devices are different hardware, but the same type of sensor
The frequency of calling the slot shouldn't be a problem, but the time needed to execute the slot.
So is that something I can influence? Since there is one slot for each device which are independent, why it is for one slot not a problem but for the other one it is? And do you think putting the slots, signals and function of the second device in another thread (worker thread) would help out? As I said, after deploying the app and starting 2 instances of it, the problem still occured for one device.
Just a note - this is not the correct way to convert a QByteArray to a string:
newValue = newValue + (QString)value;
Hmm, but this worked for me so far..
-
@jsulm Thank you! Yes these two devices are different hardware, but the same type of sensor
The frequency of calling the slot shouldn't be a problem, but the time needed to execute the slot.
So is that something I can influence? Since there is one slot for each device which are independent, why it is for one slot not a problem but for the other one it is? And do you think putting the slots, signals and function of the second device in another thread (worker thread) would help out? As I said, after deploying the app and starting 2 instances of it, the problem still occured for one device.
Just a note - this is not the correct way to convert a QByteArray to a string:
newValue = newValue + (QString)value;
Hmm, but this worked for me so far..
@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
why it is for one slot not a problem bot for the other one it is?
I don't know. Mybe something wrong with one of the devices?
What is not clear: is this slot used for both devices ConnectionClass::updateDataSlot? If so, are you aware that this slot writes data into same newValue even if you use two ConnectionClass instances? -
@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
why it is for one slot not a problem bot for the other one it is?
I don't know. Mybe something wrong with one of the devices?
What is not clear: is this slot used for both devices ConnectionClass::updateDataSlot? If so, are you aware that this slot writes data into same newValue even if you use two ConnectionClass instances?wrote on 18 Nov 2020, 12:32 last edited by SpaceToonI don't know. Mybe something wrong with one of the devices?
It was also my first thought that a device might be broken. But since the problem occurred with both devices (sometimes with one, sometimes with the other, I cannot influence this) it must have something to do with my application.
What is not clear: is this slot used for both devices ConnectionClass::updateDataSlot? If so, are you aware that this slot writes >data into same newValue even if you use two ConnectionClass instances?
I have my own updateData slot for the first device and an updateData_secondDevice Slot for the other device. So only for testing I copied the complete code for one device for the other device so that they are independent of each other. Of course you shouldn't copy code unnecessarily, but it was only for testing purposes to see if it would work with two devices at the same time at all.
EDIT: Here is where I get the conversion from QByteArray to QString: https://stackoverflow.com/a/37802857
-
I don't know. Mybe something wrong with one of the devices?
It was also my first thought that a device might be broken. But since the problem occurred with both devices (sometimes with one, sometimes with the other, I cannot influence this) it must have something to do with my application.
What is not clear: is this slot used for both devices ConnectionClass::updateDataSlot? If so, are you aware that this slot writes >data into same newValue even if you use two ConnectionClass instances?
I have my own updateData slot for the first device and an updateData_secondDevice Slot for the other device. So only for testing I copied the complete code for one device for the other device so that they are independent of each other. Of course you shouldn't copy code unnecessarily, but it was only for testing purposes to see if it would work with two devices at the same time at all.
EDIT: Here is where I get the conversion from QByteArray to QString: https://stackoverflow.com/a/37802857
wrote on 18 Nov 2020, 13:05 last edited by@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
EDIT: Here is where I get the conversion from QByteArray to QString: https://stackoverflow.com/a/37802857
Then follow either of the solutions given there, not the code you wrote!
-
@SpaceToon said in Can calling a slot too often lead to delays in data transfer?:
EDIT: Here is where I get the conversion from QByteArray to QString: https://stackoverflow.com/a/37802857
Then follow either of the solutions given there, not the code you wrote!
6/7