QThread or QTimer or something better for port control

[andreoq]

hello, i am controlling with an arm system a GPIO port (similar like parallel port). The Port sends tacts to move step motors.

My Problem is: If i just control the motors, than GUI doesnt work. Easy solution is: qApp->processEvents(). But than comes another problem. If i interact with my GUI, the motors doesnt running with constant speed, also tact frequency changes because of processEvents().

I found that QTimer can give tacts till 1khz (also max. every 1 ms) but i need higher frequencies. Should i use a QThread? I have a 400Mhz process. He should be controll the motors and stay GUI "alive" without distortion.

I also could improve QIODevice anyhow that he sends the commands(tacts) constantly.

What would you prefer? I didnt found similar applications.
thanks

[high_flyer]

I found that QTimer can give tacts till 1khz (also max. every 1 ms) but i need higher frequencies. Should i use a QThread? I have a 400Mhz process.

Be warned, that normal PC's, or lets say, OS's, have a resolution of about ~1ms. (on user space level)
So unless you are running this on a special real time system, you wont be able to get better resolution than 1ms.

Now, even if you have system that has a micro second resolution, you can't use QTimer, since it has an ms resolution.

My advice to you, in this case, is not to use Qt for controlling the motors, but just for GUI.
Use a specializes realtime lib that is designed to control step motors, and run that in a separate thread than your GUI.

If you still want to use Qt for controlling the motors, then you can either subclass QTimer, or, write your own triggering thread based on QThread (QThread as a usleep() which in microsecond resolution - but this is highly dependent on the system it runs on!)

[andreoq]

i also saw right now that qthread has usleep(), also in microseconds, which should solve my problem, but i didnt still made a hardware test.

you mean there is a realtime lib for motor controlling? i couldnt find it, but for me is just important that the motors doesnt stop just because of GUI calls, also i dont expect high resolution.

[ChrisW67]

I assume you are trying to implement some sort of pulse width modulation or the like (RC servos come to mind). The typical approach to this is hardware timers that run independently, which means low level, timer interrupt driven code that keeps the signals up to the device while providing a higher level interface for a control UI.

[high_flyer]

you mean there is a realtime lib for motor controlling?

No, (although there might be) I meant what ChrisW67 said.
Such tasks usually are not done by a high level systems, but very low level, where you use the hardware timers, and/or dedicated PWM modules.

[andreoq]

hello,

i made some hardware test and didnt get really what i wanted.

Principal works it alright but the motors (3 of them) running very slowly. Anyway works GUI normal and doesnt affect on motors. If i set the usleep time for 1microsecond, then usleep(1) is almost ignored and GUI affects on the motors. The motors doesnt turning but i hear the sound how its change if i use the GUI.

I think usleep(1) is just useless.

Can i make another pause with QMutex or Interrupts something like this? processEvents() is useless also, because it prefers GUI events than Outputevents.

[andreoq]

i would just declare my solution after months

The solution is to develope a device driver under linux (char driver). Also user-land applications are not precise enough to control stepmotors.
I heard that windows will soon enable to programm the device drivers easily like linux.