Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Ich brauche für ein Projekt einen genauen Zeitstempel. (Es geht darum: Ich lasse von einem Kameratreiber Videoframes capturen und muss in LabVIEW für jeden Frame einen ms-Zeitstempel mitschreiben. Falls Frames verloren gehen, daß man für die restlichen trotzdem noch ihr Timing kennt.)
Nun habe ich festgestellt, daß sowohl das "Get Date/Time in Seconds", als auch "Elapsed Time" meine Zeit zwar nominell angeblich in Millisekunden stoppen können, aber es zeigt sich eine Quantelung. Ich erlebe mehrere Schleifendurchläufe in angeblich der selben Millisekunde, es vergeht also angeblich KEINE Zeit. Kann aber nicht sein, es vergehen in Wahrheit mindestens 1/Framerate=10ms, so mal als Beispiel.
Ich hab das in anhängendem vi (LV 8.0) einmal zusammengekocht. Man sieht am Graphen, daß die Kurve treppenförmig ist. Die Schleife wird viel öfter durchlaufen, als daß TimeElapsed auch weiterzählt.
Wie sind diese Spünge zu erklären und noch wichtiger: Wie bekomme ich Abhilfe?
Ich habe es schon mit einem TimedLoop versucht: Super, keine Treppchen, allerdings erhalte ich damit nur das Timing von Beginn oder Ende der Schleife (und alle Differenzen nach Herzenslust, ich weiß). Ich brauche aber den Zeitstempel von erst 2-3 Nodes nach Eintritt in die Schleife. Wie lange diese Nodes wiederum dauern, weiß man nicht, das schwankt.
Hat jemand noch eine andere Idee? Kann man irgendwie per kernel32.dll-Aufruf die Systemzeit abgreifen? Vielleicht ist die ja präziser? Wird leider als struct geliefert. :-(
Wa Du beschreibst, kann ich an Deinem VI weder beobachten noch wäre es plausibel. Das Updaten eines Graphen oder Diagramms dauert mehrere Millisekunden, und es ist noch mehr, wenn Du die automatischen Skalenanpassung aktiviert hast. Demzufolge ist die Laufzeit für einen Schleifendurchgang erheblich größer als der Timerwert von 1 ms. Und das zeigt die elapsad Time auch an, also viel zu große Werte und nicht wie Du sagst zu kleine Werte.
Außerdem war meines Wissens auf den 1ms-Wert bei den Timerangaben noch nie Verlass, es scheint erst ab 2ms richtig zu funktionieren. Das nachfolgende Beispiel zeigt, daß 1000 Durchlaufe zu 1ms insgesamt fast 2 sec beanspruchen. Bei Timerwerten ab 2ms stimmt dann alles exakt.
' schrieb:Außerdem war meines Wissens auf den 1ms-Wert bei den Timerangaben noch nie Verlass, es scheint erst ab 2ms richtig zu funktionieren. Das nachfolgende Beispiel zeigt, daß 1000 Durchlaufe zu 1ms insgesamt fast 2 sec beanspruchen. Bei Timerwerten ab 2ms stimmt dann alles exakt.
[attachment=41926:Zeit5.png]
da kann ich nur zustimmen. Unter Windows darf man nicht erwarten, dass ein Timing "um die" 1000 Hz wirklich "genau" ist. Vielleicht geht das mit der Timed Loop? bestätigen kann ich das nicht, ich hab noch keine wirklich sinnvolle Anwendung für die Timed Loop unter Windows gefunden.
Unter RT dagegen ist auf eine 1 ms Angabe tatsächlich verlass. Wenn man das benchmarkt steht die Anzeige wie ne 1 (Achtung, Wochtwitz)
@Peter: ich denke, dass die Funktion "Get System Time" genau diesen DLL-Aufruf durchführt und das Strukt in einen LabVIEW Zeitstempel (aus C-Programmierer-Sicht ebenfalls ein Struct) umwandelt
Habe mich noch mal mit der Sache beschäftigt. Was ich über den zusätzlichen Zeitbedarf für das Updating des Graphen sagte, gilt zwar weiterhin. Aber trotzdem hatte Peter auch recht. Unglaublich aber wahr: Die Zeitausgabe des Elapsed-Time-VI ist tatsächlich geqantelt. Genau gesagt: Ein Zeitquant ist 1/60 s und nicht, wie mam annehmen sollte 1/1000 s.
Mit dem VI "Timerwert auslesen" hat man das nicht. Also: Problemlösung = Tipp von Mike + Updatezeit der Graphen besser managen.
Man könnte ja das Express-Vi öffnen und die Ursache erforschen. Habe ich jetzt nicht getan.
Hier das abgewandelte Elapsed Time-VI, welches das beweist: ElapsedTimeTest_1_.vi (Größe: 53,63 KB / Downloads: 202)
Und hier noch zwei Schnappschüsse von den Ergebnissen - es könnte ja sein, daß der Effekt bei besseren Rechnern als dem meinigen nicht auftritt:
Wenn ich so zurück denke ... gibt es drei Möglichkeiten für eine Zeitauflösung.
QueryPerformanceCounter - ist von der Prozessorfrequenz abgeleitet und prinzipiell auf ns genau. Dann gibt es GetTickCount, der auf ms genau ist. Und drittens gibt es aus alten Zeiten, als Prozessoren noch mit 4,77MHz liefen, ein Raster so um die 18ms. Dieses Raster taucht ab und zu noch mal auf. Das letzte mal hatte ich es unter W2K gesehen. Ob es noch immer einen API-Befehl gibt um diesen Wert zu lesen weiß ich nicht.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
16.09.2008, 12:47 (Dieser Beitrag wurde zuletzt bearbeitet: 16.09.2008 12:57 von Lucki.)
' schrieb:ich hab das mal gemacht und man sieht: NICHTS
Nach den Gesetzen der Logik heißt das doch, daß die dort verwendete Funktion Gettime bereits dieses mysteriöse Verhalten an sich haben muß. (Und das deckt sich mit dem, was Peter ganz oben schon festgestellt hat)
Und das stimmt wirklich, habe das VI weiter oben erweitert um den Fall: "Zeiterfassung mit Get Time" und das VI oben ersetzt.
Und IchSelbst hat uns auch die Augen geöffent, warum das so ist: 1/60 s = 16.7 ms = Wert um die von Ich Selbst genannten 18 ms. Die Windows-Zeitanzeige benutzt offenbar bis heute diesen Takt.
Das ist ja alles nicht so schlimm, wenn man es weiß. Ein entsprechender Hinweis in der LV-Hilfe bei diesen Funktionen wäre wirklich nicht schlecht.
Hier der Schnappschuss bei Zeiterfassung mit Get Time:
)
