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!
Dritter Fehler: Du holst einmal pro Sekunde ein Datenpaket aus deiner Queue. Das bedeutet nicht, dass dieses Paket das aktuellste ist oder die Daten der letzten Sekunde enthält: Du holst nur das älteste Paket aus der Queue!
Queues arbeiten nach dem FIFO-Prinzip!
Okay. Das macht auch Sinn. Also muss es in die gleiche Consumer-Schleife.
Im NI-Forum habe ich ein ähnlichen Thread gefunden: Link
Dabei wird im weiteren darauf eingegangen, dass ein Counter-Task erstellt wird:
Zitat:Do you mean that you want to count how many events have occurred every millisecond? If so, you might want to do a continuous buffered event counting. This would help ensure that you don't miss counts (like you would if you had to stop the counter task and restart it for every count read).
Aber das wäre in meinem Fall schon zuviel, dass Signal ist ausgewertet ja schon vorhanden, es soll ja nur noch einem Bin in einem Histogramm zugeordnet werden...
Nachdem ich gestern Abend im NI-Forum eine Frage dazu gestellt habe (Zur Vollständigkeit hier der Link)
Habe ich mein Problem zusammengefasst weil jemand nachgefragt hatte und die Nacht darüber geschlafen. Und siehe da, heute morgen ist mir eine Idee zur Lösung gekommen.
Wenn ich nun eine Integration von diesen Daten vornehme und dt meine gewünschte Bin-Breite ist, sollte die Integration mit die Separierung der Daten vornehmen der Form, wenn dt zum Beispiel 10ms ist:
Nun muss ich schauen wie ich es hinbekomme, dass LabVIEW mit nur die Menge der Einträge innerhalb dt integriert und nicht den Wert der Einträge. Und dies dann fortlaufend dargestellt sollte mir den gewünschten Graphen erzeugen. Dann sollte ich nicht einmal die Histogramm-Funktion benötigen.
Eigentlich dachte ich die groben Fehler mit dem DAQ-Assistant umgehen zu können. Aber offensichtlich liegt da doch noch etwas im argen.
Aktuell bekomme ich immer diese Fehlermeldung:
Zitat:Error -200141 occurred at FCS-ProCon.vi:Instance:3:510001
Possible reason(s):
Data was overwritten before it could be read by the system.
If Data Transfer Mechanism is Interrupts, try using DMA or USB Bulk. Otherwise, divide the input signal before taking the measurement.
Task Name: _unnamedTask<0>
Anscheinend kommen die Signale schneller rein, als der DAQ-Assistent sie weiterreichen kann.
Meine Überlegung geht in die Richtung, dass aus der APD(Avalanche Photo-Diode) die Pulse durchaus mit 20ns Abständen rauskommen können, das NI-6210 ist aber nur bis 250kS/s verifiziert.
Könnte sich der Fehler darin begründen, dass bei zwei Photonen die zwei Pulse mit weniger Abstand als 1/250.000 s das Gerät so überfordern, dass er sie nicht weitergeben kann?
Würde sich das Problem lösen lassen, wenn man den DAQ-Assistenten durch normale Task's ersetzt? (Wobei, dann dürfte es nicht an der HW von NI liegen, wenn es ein Software Problem wäre)
07.04.2014, 15:50 (Dieser Beitrag wurde zuletzt bearbeitet: 07.04.2014 15:52 von GerdW.)
Zitat:Eigentlich dachte ich die groben Fehler mit dem DAQ-Assistant umgehen zu können. Aber offensichtlich liegt da doch noch etwas im argen.
Ja, die groben Fehler lassen sich vermeiden. Die Feinheiten dagegen sind eher was für's Tuning per DAQmx-Funktionen…
Zitat:Anscheinend kommen die Signale schneller rein, als der DAQ-Assistent sie weiterreichen kann.
Jein. Die Daten kommen anscheinend schneller, als sie abgerufen werden…
Ist der USB evtl. überlastet?
Zitat:Meine Überlegung geht in die Richtung, dass aus der APD(Avalanche Photo-Diode) die Pulse durchaus mit 20ns Abständen rauskommen können, das NI-6210 ist aber nur bis 250kS/s verifiziert.
Du darfst die Samplerate nicht mit der max. Pulsrate der Counter verwechseln. Die CTR sind lt. Specs mit bis zu 80MHz angegeben, d.h. erlauben Signale mit 12.5ns Flankenabstand…
Hast du den CTR auf die maximale Taktfrequenz gesetzt?
Kannst du den CTR evtl. auch mit geringerer Samplerate abfragen? Der CTR wird weiterhin alle Pulse zählen, du wirst nur etwas seltener einen Zwischenstand abfragen…
Zitat:Würde sich das Problem lösen lassen, wenn man den DAQ-Assistenten durch normale Task's ersetzt?
Hi GerdW,
so langsam habe ich das Gefühl du wohnst hier im Forum
Aber dennoch danke ich dir wieder für deine Antworten
(07.04.2014 15:50 )GerdW schrieb: Ja, die groben Fehler lassen sich vermeiden. Die Feinheiten dagegen sind eher was für's Tuning per DAQmx-Funktionen…
Das dachte ich mir schon, dann muss ich mir mal anschauen, wie man so eine Task-Abfolge erstellt. Aber da lassen sich sicher Anleitungen hier im Forum bzw. im Internet finden. Muss ich nur schauen, ob ich das auch von Zuhause machen kann, ohne den DAQmx Zusatz.
(07.04.2014 15:50 )GerdW schrieb: Jein. Die Daten kommen anscheinend schneller, als sie abgerufen werden…
Ist der USB evtl. überlastet?
Am USB hängt ausschließlich das NI-Gerät. Ich glaube sogar die Maus ist noch eine PS/2 Maus. *G*
Ich dachte durch die Installation der Queue in die VI sollte keine Stauung insofern auftreten, dass die Daten nicht schnell genug verarbeitet werden können.
An der Integration die direkt in der Producer-Schleife hängt kann es ja nicht liegen, die dürfte nicht zuviel abverlangen.
(07.04.2014 15:50 )GerdW schrieb: Du darfst die Samplerate nicht mit der max. Pulsrate der Counter verwechseln. Die CTR sind lt. Specs mit bis zu 80MHz angegeben, d.h. erlauben Signale mit 12.5ns Flankenabstand…
Ah, okay. Das hatte ich dann durcheinander geworfen. Dann dürfte dort nicht das Problem liegen. Kurios ist, dass die Dunkelzählrate mit 200 Photonen/s sowie leichte Messungen mit 5000 Photonen/s kein Problem sind, nur wenn es mehr wird, steigt er nahezu instant nach starten des Prozesses mit obiger Fehlermeldung aus.
(07.04.2014 15:50 )GerdW schrieb: Hast du den CTR auf die maximale Taktfrequenz gesetzt?
Kannst du den CTR evtl. auch mit geringerer Samplerate abfragen? Der CTR wird weiterhin alle Pulse zählen, du wirst nur etwas seltener einen Zwischenstand abfragen…
Ich glaube das das beim DAQ-Assistenten gar nicht einzustellen geht. Dort habe ich ihn nur ausgewählt, kontinuierliche Messung gewählt und in der Sample-Rate 1 eingesetzt. Im kontinuierlichen Modus stellt dies die Buffer-Größe dar. Mit der 1 wird eben sofort jeder Puls ausgegeben, klappte bisher sehr gut, dadurch wird meine "Messzeit"-Berechnung genauer. Aber selbst mit großen Werten bzw. Buffern erfolgt die Fehlermeldung nach starten des Prozesses.
Zitat:Es würde zumindest die Übersicht im VI erhöhen.
(07.04.2014 17:07 )jg schrieb: Dann hoffe ich mal, dass der USB-Port nicht noch USB 1.1 ist...
Das denke ich eigentlich nicht. Der Rechner ist ein Dual-Core. Die sollte es eigentlich nicht mehr in Verbindung mit USB 1.1 geben. Da werde ich morgen direkt mal nachschauen. Aber wie gesagt, denken würde ich es eher nicht.
Ich bin leider noch nicht dazu gekommen, den DAQ-Assistenten umzuschreiben, weil ich mir noch Gedanken über die gemittelte Autokorrelation mache.
Dafür habe ich den unteren Teil mit dem zeitlichen Histogramm kopiert und als weiteres Element in die Consumer-Schleife eingefügt. Dann hab ich anstatt einer variablen Bin-Breite die gewünschte 0,0001 bzw. 10000 Bins pro Sekunde gesetzt.
Nun kommen dauerhaft Bins mit 0,0001s Breite aus dem Histogramm. Danach müsste ich mich etwas bauen, was immer genau 10000 entgegennimmt und in die Autokorrelations-VI wirft. Die Daten nach der VI werden dann mit allen späteren Autokorrelationen addiert und durch die Anzahl an Autokorrelationen geteilt.
Bisher sieht mein Ansatz so aus:
Photon_autocorr.vi (Größe: 81,48 KB / Downloads: 125)
Kann man ein Cluster aus den Histogramm Daten erstellen, welches 10.000 Spalten hat in denen je die Bins für die Sekunde kommen, jede Zeile würde dann eine Sekunde präsentieren. Die Daten aus dem Histogramm werden fortlaufend eingefügt und immer wenn eine Zeile voll ist werden die Einträge und die Autocorr geworfen, mit den Autocorrelationen der anderen anderen Zeilen dann addiert und durch die Anzahl der Zeilen geteilt.
/
Logarithmische Signaldarstellung
