Zeitversatz zwischen Drehzahl- und Winkelmessung

Hallo,

auch Dir vielen Dank für Deine Unterstützung.

(07.06.2011 20:27 )cheggers schrieb:  - die beiden Counter Task sind nicht synchronisiert. Möglich dass dadurch eine Zeitverschiebung resultiert

Leider beschwert sich LabVIEW, wenn ich den Frequenz-Task per Sample Clock-Timing betreiben will - die Hardware kommt mit der Betriebsart dann nicht klar. Daher bin ich hier leider auf implizites Timing festgelegt, womit an sich ein Zeitversatz zwischen der Frequenzmessung und den Analog-Eingängen möglich ist. Wobei dieser - da es sich ja um einen Offset der Task-Startzeitpunkte handelt - konstant sein müsste; mein Offset ist dagegen zeitlich variabel...
Interessanterweise passt der Frequenz- bzw. Drehzahltask gut mit den Analogeingängen zusammen. Ärger macht der Winkel-Task, der ja per Sample Clock-Timing synchron mit dem AI-Task läuft...

Zitat:- die Messung ist überall auf "kontinuierlich" gestellt obwohl es sich um eine Finite handelt

Letztendlich ist doch jede Messung finit - oder sind Messysteme, die bis in alle Ewigkeit weiterlaufen, schon erfunden? ;-)
Ich habe mich hierbei (LabVIEW-Einsteiger...) an diversen Beispielen aus dem Example Finder und Codeschnipseln aus dem Netz orientiert; in den Fällen war das Timing immer auf "kontinuierlich" gestellt, wenn die Daten in einer Loop angefragt wurden (dazu weiter unten mehr).
So, wie ich das verstanden habe, läuft ein "kontinuierlicher" Task ab dem Starten des Tasks weiter, bis er dann explizit per "DAQmx Clear Task" beendet wird; ein "finiter" Task beendet sich dann - ebenfalls nach meinem Verständnis - selbst, wenn er die angegebene Anzahl an Samples aufgenommen hat.

Zitat:- bei einen gepufferten analogen Output werden zuerst die Daten geschrieben, dann erst der Task gestartet (siehe Example Finder). Zudem wird ein leerer 1D Array auf den AO geschrieben (?)

Das leere Array ist gewissermaßen ein Platzhalter für das Array, das da tatsächlich geschrieben wird - so, daß man erkennen kann, auf welche Weise der Write-Block mit Daten versorgt wird. Ich hatte aus hoffentlich verständlichen Gründen keine große Lust, hier ein Array mit ~90.000 Elementen in den Screenshot einzubauen...

Es gibt im selben Prüfaufbau auch eine weitere Messart, bei der die Länge der Messung nicht vordefniert ist, sondern allein von Benutzereingaben abhängt. Das können dann wenige Sekunden sein - oder auch mal eine halbe Stunde oder noch länger... Wenn ich die Daten vor dem Start des Tasks in einem Rutsch an den DAQmx Write übergebe, dann müssen diese Daten (20.000 Samples pro Sekunde) ja irgendwo gepuffert werden. In den FIFO der Messkarte passen sie wohl eher nicht, es muß also der RAM des Rechners sein - und der ist (auf dem hier vorliegenden PXI-Controller) ohnehin nicht all zu üppig.
Daher werden für diese Messart dann die Drehzahlvorgaben zur Laufzeit in der Mess-Loop erzeugt (durch ein Sub-VI); ergo muß da (für diese Messart) ein Write-Block in die Loop herein (es müssen ja in jedem Durchlauf die frisch erzeugten Werte geschrieben werden). Da ich eine gemeinsame grundlegende Struktur für alle Messarten haben wollte (das reduziert den Wartungsaufwand), ist auch in der hier geposteten Messung eben der Write-Block in der Loop enthalten (obwohl hier die zu schreibenden Daten außerhalb der Loop vordeiniert sind).
Ich meine, auch ein entsprechendes Beispiel mit DAQmx Write in einer Schleife im Example Finder gesehen zu haben...

Zitat:- für was ist die for-Loop gedacht. Das Timing in dieser for-Loop ist überflässig, da ja die DAQmx VIs (Timing VI) das Timing vorgibt

Ohne Schleife habe ich es nicht hinbekommen, daß LabVIEW mir die Kanäle gleichzeitig aufzeichnet. LabVIEW hat dann immer zuerst den ai Task abgearbeitet; dann, wenn dieser durch war, den ao-Task; wenn dieser abgeschlossen war, wurden Winkelmesswerte aufgenommen; und wenn diese allesamt im Kasten waren, kam die Drehzahlmessung. Dabei steht der Aufbau also während der Datenerfassung still,. und nur dann, wenn gerader nichts gemessen wird, dreht er - das ist so nicht gedacht!
Die Schleife macht jetzt zweierlei:
- Zum Einen stellt die Schleife an sich eine Art "atomare Einheit" dar - soll heißen, es wuird erst der Code vor der Schleife abgearbeitet, dann die Schleife, und dann der Code nach der Schleife. Im Ergebnis werden also erst alle Tasks eingerichtet & gestartet, dann kommt die Schleife, und erst nach Schleifenende werden die Tasks beendet. Es sind also während die ASchleife läuft schon mal alle Tasks zeitgleich aktiv.
- Zum Anderen holt die Schleife von jedem Task in regelmäßigen Abständen die aufgelaufenen Messwerte ab - so kann ein einzelner Task nicht den FIFO der Karte vollschreiben, und die Messung kann weiter laufen, bis die Schleife letztendlich abgearbeitet ist.

Ich hoffe, ich habe da nicht all zu viele Denkfehler drin - lasse mich aber auch gerne eines Besseren belehren! ;-)