Qt Precise Timer

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
yannisulrich
Beiträge: 3
Registriert: 03 Mär 2018, 16:12
Wohnort: Schweiz

Qt Precise Timer

Beitrag von yannisulrich » 10 Apr 2018, 17:04

Hallo,

Ich verwende jetzt seit ein paar Monaten die Community-firmware. Ich habe mit Hilfe eines Oszilloskops gemessen, wie regelmäßig und wie schnell der TXT einen Motorausgang takten kann. Das Programm auf dem TXT ist sehr einfach, es wechselt einfach den ausgang alle "x" milisekunden von an zu aus oder andersrum. Dabei ist mir aufgefallen, dass mein Programm auch bei langen zeiten Schwierigkeiten hatte, im richtigen moment zu takten. Nach Google-Suche hab ich dann erfahren, dass es in Qt unterschiedliche Timer gibt, und das der default ein sogennanter Coarse Timer ist, also recht grob. Es ist in PyQt prinzipiell möglich, präzisere Timer zu implementieren, theoretisch folgendermaßen:

Code: Alles auswählen

self.timer = QTimer(self)
self.timer.setTimerType(Qt.PreciseTimer)
self.timer.timeout.connect(self.on_timer)
self.timer.start(dt*1000)              
Doch dies gibt mir die Fehlermeldung, die QTimer Class habe kein "setTimerType" attribute. Ist es momentan möglich, mit der Community-Firmware einen QtPreciseTimer zu verwenden, oder hängt dies von der vorhanden Qt installation ab? Ich habe im Anhang vier Bilder des Oszilloskopen bei verschiedenen Taktfrequenzen. Das ergebnis bei 10ms ist wahrscheinlich eine Grenze der I/O ports.

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Qt Precise Timer

Beitrag von richard.kunze » 10 Apr 2018, 18:45

Hallo,
yannisulrich hat geschrieben:Ist es momentan möglich, mit der Community-Firmware einen QtPreciseTimer zu verwenden
Nein. QtPreciseTimer gibt es erst seit Qt5, aber die CFW verwendet noch Qt4. Und Umstellen auf Qt5 ist leider nicht so einfach möglich, weil mit Qt5 ein Multiplex-Betrieb von mehreren Programmen die Zugriff auf den Touchscreen brauchen (in der CFW ist das der Launcher und die verschiedenen Apps) nicht mehr geht ohne gleich ein komplettes Windowing-System (entweder X Windows oder Wayland) zu benutzen...
yannisulrich hat geschrieben:Ich habe im Anhang vier Bilder des Oszilloskopen bei verschiedenen Taktfrequenzen. Das ergebnis bei 10ms ist wahrscheinlich eine Grenze der I/O ports.
Anhänge sehe ich hier keine, aber die 10ms sind der maximale Takt, mit dem der Linux-Teil des TXT (auf dem die CFW läuft) Daten mit dem Microcontroller-Teil (der die Ausgänge dann tatsächlich schaltet) austauschen kann. Schneller geht mit dem TXT nicht.

yannisulrich
Beiträge: 3
Registriert: 03 Mär 2018, 16:12
Wohnort: Schweiz

Re: Qt Precise Timer

Beitrag von yannisulrich » 11 Apr 2018, 12:39

Danke für die schnelle Antwort. Mit den Anhängen scheint irgwendetwas schief gegegangen zu sein, ich hänge sie hier nochmal drann.
Dateianhänge
TXTpulse10ms.png
TXTpulse20ms.png
TXTpulse50ms.png

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Qt Precise Timer

Beitrag von MasterOfGizmo » 11 Apr 2018, 13:28

Um einen Eindruck zu bekommen, ob Qt oder die Hardware der Flaschenhals ist lohnt es sich z.B. an Qt vorbei einfach so schnell wie möglich den Port zu setzen und zu löschen.

Mir war gar nicht bewusst, wie langsam der TXT an der Stelle ist.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Stuessi
Beiträge: 48
Registriert: 03 Aug 2016, 15:15

Re: Qt Precise Timer

Beitrag von Stuessi » 11 Apr 2018, 13:57

Hallo,

ich komme auf minimal 4,25 ms pro Schritt
wenn ich einen Schrittmotor am ROBO Interface im Halbschrittverfahren unter startIDE vom TX-Pi aus steure.
(17 s für 4000 Schritte)

Gruß
Rolf

Benutzeravatar
PHabermehl
Beiträge: 2429
Registriert: 20 Dez 2014, 22:59
Wohnort: Bad Hersfeld

Re: Qt Precise Timer

Beitrag von PHabermehl » 11 Apr 2018, 14:43

MasterOfGizmo hat geschrieben:Mir war gar nicht bewusst, wie langsam der TXT an der Stelle ist.
Rolf hatte ja schon nachgewiesen, dass der TX-Pi den ftDuino über USB schneller bedienen kann als der TXT seine I/O intern...

Gruß
Peter
https://www.MINTronics.de -- der ftDuino & TX-Pi Shop!

viele Grüße
Peter

yannisulrich
Beiträge: 3
Registriert: 03 Mär 2018, 16:12
Wohnort: Schweiz

Re: Qt Precise Timer

Beitrag von yannisulrich » 11 Apr 2018, 15:04

Ich habe gerade mit einem reinen Python-script getestet, wie schnell der TXT die Ausgänge taktet. In einem einfachen while True loop ist das Ergebnis sehr unregelmäßig und die Periode um die 50ms. ich habe unterschiedlichen Frequenzen für mein Programm getestet, und komme bestenfalls an eine Periode von 20ms ran, und das interessanterweise wenn ich das Programm alle 15ms laufen lasse. Das selbe Ergebnis erreiche ich auch mit einem Qt Timer bei 15ms, allerdings ist dieser weniger regelmäßig. Im Anhang ist ein Bild mit reinem Python mit 15ms, und Qt mit 15ms.
Dateianhänge
TXTpulse20msPython.png
TXTpulse20msQt.png

Stuessi
Beiträge: 48
Registriert: 03 Aug 2016, 15:15

Re: Qt Precise Timer

Beitrag von Stuessi » 11 Apr 2018, 16:19

Hallo,

fast saubere Rechteckschwingungen kann ich mit TX-Pi und ROBO bis 50Hz erzeugen.

Bild

Statt delay 10 verwende ich in startIDE eine Timerabfrage

Tag a
Output FTD 1 512
TimerClear
Tag b
IfTimer < 10 b
Output FTD 1 0
TimerClear
Tag c
IfTimer < 10 c
Jump a

Mit TX-Pi am ftDuino erhalte ich damit gleichförmige Rechteckschwingungen mit 44 Hz

Bild

Mit TX-Pi und ftDuino klappt es sogar noch mit Timer-Werten unter 10:

5: 79 Hz
3: 100 Hz
2: 130 Hz
1: 192 Hz

Bild

Gruß
Rolf

Torsten
Beiträge: 308
Registriert: 29 Jun 2015, 23:08
Wohnort: Gernsheim (Rhein-Main-Region)

Re: Qt Precise Timer

Beitrag von Torsten » 12 Apr 2018, 09:24

Hallo,
MasterOfGizmo hat geschrieben:Um einen Eindruck zu bekommen, ob Qt oder die Hardware der Flaschenhals ist lohnt es sich z.B. an Qt vorbei einfach so schnell wie möglich den Port zu setzen und zu löschen.

Mir war gar nicht bewusst, wie langsam der TXT an der Stelle ist.
an dieser Stelle könnte auch die ftrobopy-library der Flaschenhals sein. Der python(!)-thread für die Kommunikation zwischen der Linux-Platine und der Motorplatine des TXT ist nicht sehr schnell. Mit reinem C Code erreicht man auf dem TXT deutlich bessere Werte. Ich werde bei Gelegenheit nochmal ordentliche Messungen mit reinem C Code machen und hier einstellen. (Soweit ich mich erinnere sind mindestens 10 ms Schaltzeiten möglich, evtl. sogar 1 ms, ich weiss es nicht mehr genau).

Torsten

Antworten