Timing Problem für Counter

Hallo,

ich Arbeite zur Zeit an einem einfachen Zähler.
Das Messinstrument gibt TTL Signale an die NI PCI-6035E Karte gesendet.
Die Signale Zähle ich über den Internen Counter aus.
Ziel ist es am Ende Zeitaufgelöst die Ereignisse darzustellen.

Ich habe ein Screenshot des Programms einmal angehängt.

Zur Zeit gebe ich mit einem Freuqenzgenerator TTL Signale auf die Messkarte ab einer Freuqeunz von etwa 1kHz fällt auf, dass das zweite Auszählen scheinbar zu einem Willkürlichen Zeitpunkt erfolgt obwohl es erst nach der vorgegeben Messzeit erfolgen soll. Das interesante ist, es liegen immer zuwenig Messwerte vor.

Hier noch einmal der Ablauf Grob:
Programm Startet -> Der Counter wird Gestartet -> Die Schleife wird betreten -> Der Erste Wert wird ausgelesen (Und zwar die Korekkten 0 Counts) -> Die Schleife wartet die Messzeit (soll es zumindestens) bis zur nächsten Ausführung-> der counter wird ausgelesen und die Zahl wird gespeichert *-> Scheleife wartet wieder -> usw

* An der Stelle hier scheint ein Fehler zu sein da nicht die Korrekte Anzahl ausgelesen wird bzw in dem Schritt davor weil nicht die richtige Zeit gewartet wird.

Wo könnte der Fehler liegen oder was könnte das Problem verursachen ?
Schon einmal Danke im Voraus

Gruß

Alex

Anzeige

Hallo Aldero

Es ist nicht definiert, ob das Warten vor oder nach dem Einlesen der Daten ausgeführt wird, da alle Zweige in der Schleife parallel abgearbeitet werden.

Ausserdem hat das verwendete Metronom die Eigenschaft, dass es sozusagen initialisiert werden muss. Beim ersten Mal wird nicht die angegebene Zeit gewartet, sondern immer bis zu einem Vielfachen der angegebenen Zeit vom Beginn der LabVIEW Session. Ein einfacher Delay ist vielleicht besser an dieser Stelle.

Gruss, BDB

Das SW-Timing kannst du für solche Aufgaben vergessen! Zu ungenau was Windows da veranstaltet...

Hm, was genau ist das SW Timing ? Ich arbeite zum ersten mal mit LabVIEW also nicht böse sein wenn ich triviale Fragen stelle

Ich habe einmal Time Delay benutzt anstat das Metronom, jedoch behebt es das Problem nicht.

Es gibt auf der Messkarte eine Uhr kann ich die irgendwie nutzen ?

Ich benutze jetzt die Timed While Schleife, damit schein zumindestens das Problem was oben angesprochen wurde behoben zu sein, das Programm wartet die richtige Zeit zwischen dem ersten und dem zweiten Durchlauf der Schleife ab.

Jedoch gibt es ein neues Problem.

Soweit wie ich das Programm bis jetzt verstanden habe fängt der Counter bei dem "Start" Icon an zu zählen und dann wird durch das "Read" Icon der Counter ausgezählt. Idealer weise sollte beim ersten Auslesen 0 als Count heraus kommen jedoch schwankt die Zahl bei einem TTL Signal mit 10000 Hz zwischen 8 und 250 Counts. Aus einem mir nicht verständlichen Grund scheint die Zeit bis zum ersten auslesen zwischen 0,8 ms und 25ms zu schwanken.

Woran könnte das liegen und wie kann dieses Problem umgehen ?

Du kannst mit einem "Nicht-RealTime-System" (z.b. Windows) keine deterministischen Programmabarbeitung realisieren, d.h. die Ablaufgeschwindigkeit ist nicht vorhersagbar! Auch ist deine Erfassung ja offenbar nicht mit dem Eingangssignal synchronisiert, z.B. durch eines HW-getriggerten Start (steigende Flanke).

Folglich wirst du das so nicht hinkriegen! Wenn dein Programm für den Task "Start" sagt, hat der Counter schon einige Flanken gezählt, bis du überhaupt das erste Mal in die Schleife zum "Read" kommst. Wieviele Flanken da schon gezählt wurden, hängt ganz davon ab was dein Betriebssystem noch so nebenbei macht, bis es in einer "Zeitscheibe" mal wieder deine Counter-Applikation bedienen kann und den (unabhängig laufenden) Counter abfragen kann!

Wenn du dein Eingangssignal mal spaßeshalber mit nur 1 Hz laufen lässt, und dann die Erfassung ebenfalls mit einer Schleifenwartezeit von 1 sek. abfragst, könnte deine Anwendung "pro Iteration ein Count" funktionieren. Je schneller dein Signal wird, desto ungenauer!

Wenn du eine (im Rahmen der Windows/LabVIEW-Möglichkeiten) konstante Wartezeit zwischen zwei Counterabfragen haben willst, wirst du mit einer so bescheidenen Auflösung leben müssen.

Du könntest alternativ mit einem weiteren Counter einen HW-Referenztakt (Pulse train) starten, bei dessen steigender Flanke jeweils eine (somit getriggerte) Einzelwert-Abfrage des Signal-Counters erfolgt. Beispiele dazu gibt's im LV Example Finder

Gruß
Achim

Anzeige

Hallo und danke für die Antwort.

Das das Signal und die Messung nicht Syncron sind ist mir bewusst, deshalb habe ich bei den einzelnen Zählungen auch abweichungen von +-1 Count.
Später soll das Programm an einem Röntgenstrahlungsdetektor betrieben werden und das Ziel ist es die Röntgenstrahlung zeitaufgelöst zu messen.

Die Idee ist es den Counter zu starten und nach festen Zeiten die Messkarte auslesen zu lassen.

Achim schlägt vor, dass ich einen Pulstrain benutze, ich habe mir die Beispiele angeschaut und habe darauf das Programm im Anhang gemacht.

Neues Problem ist jetzt: Wie kann ich einstellen, dass die Obere Sampelclock den Kanal: "dev/ctr0internaloutput" benutzt, in dem drop down menü kann ich es nicht finden, im Exampel steht es aber im Menü dabei.

Des weiteren erhalte ich immer die Fehler Meldung "The specified resource is reserved. The operation could not be completed as specified" Google sagt mir, dass ich angeblich immer nur einen Task einer Sorte (AI, AO, Digital, Counter) gleichzeitig haben kann. Quelle

Lösung ist das ich zwei Kanäle in einen Task legen muss. Geht das auch mit countern und wie kann ich dann einen nutzen um einen Pulstrain zu erzeugen und mit den anderen dann auslesen ?

Zum Punkt ctr-internaloutput:

Rechtsklick auf Terminal-Konstante:
   
Dann Haken bei Advanced Terminals setzen:
   

Gruß, Jens

Danke das hat mich schon einmal ein ganzes stück weiter gebracht.

Hm, irgendwo habe ich einmal gelesen, das man einen digital eingang ebenfalls als Counter benutzen könnte. Leider finde ich es nicht mehr, weiß dazu vielleicht wer mehr ?