Präzises Auslesetiming ohne Hardware Trigger

Hallo zusammen!

Der Hintergrund:

Das VI soll mit möglichst exakt 1kHz die innerhalb der letzten 1ms gezählten Flanken einer PCI 6602 Karte auslesen.
Mein Ansatz ist eine zeitgesteuerte Schleife mit DAQmx-Lesebefehl, sowie programmgesteuerter I/O am DAQmx Kanal.
Zur Kontrolle ist momentan ein Funktionsgenerator mit 1MHz angeschlossen.
Theoretisch sollte das VI in "data" einen Vektor gefüllt mit Werten = 1000 ausspucken.
Der Zeitdifferenz "x-y" (vgl. Screenshot) sollte bei 10.000 ms liegen.

Was klappt:

- "x-y" ist gleich 10.000 ms
- 99,99% der Flanken werden gezählt

Jetzt zum Problem:

Leider wird der DAQmx-Befehl "Lesen" nicht immer im Abstand 1ms aufgerufen.
Das Histogramm der Werte in "data" (siehe Screenshot) deutet darauf hin.
Im Histogramm stören die beiden Nebenmaxima bei 0 und 2000.
Meine Interpretation ist, dass der Befehl "Lesen" bei Iteration i zu spät ausgeführt wurde
-> bis zum Lesen zu viele Pulse gezählt
und "Lesen" bei Iteration i+1 wieder pünktlich ausgeführt werden konnte
-> weniger als 1 ms seit dem letzten "Lesen" und deshalb weniger gezählte Flanken

Meine Frage:

Wie kann man den Zeitpunkt zum ausführen des "Lesen"-Befehls zuverlässiger festnageln - ohne Hardware Trigger bzw. Gate-Signal.
Gibts vielleicht bei dem Modus für verspätete Iterationen der zeitgesteuerten Schleife noch potential?
Ich habe alle Modi mal ausprobiert und ohne den Unterschied wirklich zu verstehen keine Verbesserung festgestellt.

Vielen Dank!


EDIT jg: Externer Bildlink gelöscht

Anzeige

Hi
Ich denke, Deine Chancen ohne HW-Trigger auszukommen stehen sehr schlecht. Das habe ich auch einmal probiert.

Wenn Du keinen externen Trigger hast, kannst Du einen anderen Counter als Frequenzgenerator auf der Karte nutzen und das interne Signal-Routing, um seinen Ausgang als Latch-Trigger zu verwenden. Damit wäre kein externes Verkabeln nötig. Dann musst Du noch den Buffergröße richtig einstellen, damit der While-Loop-Timing-Jitter Dir keinen Strich durch die Rechnung macht.

Mit diesem Konzept bin ich sogar ohne Timed-Loop ausgekommen.

Gruß Holger

Wenn du deinen Screenshot als PNG abspeicherst, dann ist die Datei
1) viel kleiner (40 kB anstatt 3,6 MB) und
2) zweitens hier im Forum hochladbar, was laut LVF-Regeln sowieso erwünscht ist.

Gruß, Jens

(18.11.2011 12:33 )Piddi schrieb:  Das VI soll mit möglichst exakt 1kHz die innerhalb der letzten 1ms gezählten Flanken einer PCI 6602 Karte auslesen.

Habe jetzt nicht speziell bei der 6602-Karte nachgeschaut, aber normalerweise geht genau das mit jeder Universal-Messkarte, ohne daß dafür groß programmiert werden muß.

"Daqmx create Virtual Channel.vi" ist einzustellen auf: CI-Flankenzählung.
"QAQmx Timing" ist einzustellen auf "Sample Takt", Rate = 1000.
Aus dem "DAQmx Read" kommen dann als Array die Anzahl der Flanken pro ms der letzten ms heraus.

Es gibt in der Beispielsammlung unter:
Signalerfassung mit Hardware / Daqmx / Zählergstützte Messung / Zählen digitaler Ereignisse
mindestens ein Beispiel, welches massgenau zu Deiner Aufgabe passt.

Hi
ich stimme meinem Vorredner zu.

Am Sample Clock.vi kann zusätzlich der Sample Trigger (Source) ausgewählt werden. Extern oder interne Signale, die entwerden schon direkt verbunden sind, oder indirekte Routen, die über die Routing-VIs verbunden werden können. (DAQmx->Advanced->Signal Routing)

Direkte und indirekte Routen durch das System kannst Du dir MAX ansehen.

Gruß Holger

Danke erst einmal für die Antworten!
Ich habe versucht die Idee mit dem Sample Clock.vi und dem karteninternen Signal Routing umzusetzen.
Leider erhalte ich eine Fehlermeldung (siehe Screenshot). Den Sinn der Fehlermeldung glaube ich zu verstehen.

Was muss geändert werden, damit der Ressourcen-Konflikt nicht auftritt?

Anzeige

Da hat sich noch ein Fehler im VI eingeschlichen. Ändert aber nichts an der Fehlermeldung.
Jetzt mit dem richtigen Anschluss für den Sample Takt...

Hab das Problem jetzt selbst gelösts.
1.) Es ist nicht notwendig die Ausgänge (ctr1 out und ctr0 gate) extra zu verbinden, das passiert schon im Sample Takt / "Stoppuhr" VI. Deshalb kam es zu dem Ressourcen-Konflikt.
2.) Die Pulsfolge musste noch auf kontinuierlich definiert werden.

Gruß
Piddi

Kleiner Verbesserungsvorschlag:
Du solltest per Datenfluss sicherstellen, dass die Kanaleigenschaften auch wirklich vor Start des Tasks gesetzt werden.
Außerdem kannst du die beiden Eigenschaften mit einer PropertyNode abhandeln:
   
Gruß, Jens