Probleme mit Abtastrate und Anzahl Samples pro Kanal

Hallo,
ich möchte 4 Signale mit 2000Hz abtasten (also ein Wert pro 500µs pro Kanal).
Wenn ich in meinem Vi jetzt bei DAQmx-Timing die Rate auf 2000 stelle und bei DAQmx-Lesen die Anzahl Samples pro Kanal auf -1 belasse, wird mein Speicher voll.
Wenn ich in meinem Vi jetzt bei DAQmx-Timing die Rate auf 2000 stelle und bei DAQmx-Lesen die Anzahl Samples pro Kanal auf z.B. 2000 stelle, kommt nach ca. 203 sec. vom DAQmx-Lesen der Fehler:"Es wurde versucht Abtastwerte zu lesen, die nicht mehr zur Verfügung stehen. Der angeforderte Abtastwert war zuvor verfügbar, wurde jedoch überschrieben."
Was genau müssste ich denn einstellen, damit ich kein Fehler erhalte?
Gruß

  Abstand_ohneTrigger.vi (Größe: 745,52 KB / Downloads: 654)

Dein VI kann ich mir nicht ansehen, bei mir steigt LabVIEW mit der Meldung "Die Datei 'Abstand_ohne_Trigger' ist keine zulässige LV-Datei" aus..

komisch...dann die vielleicht?

  Abstand_ohneTrigger.vi (Größe: 607,98 KB / Downloads: 455)

' schrieb:Dein VI kann ich mir nicht ansehen, bei mir steigt LabVIEW mit der Meldung "Die Datei 'Abstand_ohne_Trigger' ist keine zulässige LV-Datei" aus..

vermutlich wäre es hilfreich gewesen, wenn Tetris mal diese Anleitung gelesen hätte

...also das 2.Vi kann man öffnen...zumindestens mit1

' schrieb:...also das 2.Vi kann man öffnen...zumindestens mit1

Ja, jetzt geht es zu öffnen, und ich habe mir das VI kurz angesehen. Die ai-Konfiguration ist nicht falsch. Wenn bei so einer kontinuierlichen Datenerfassung in der While-Schleife, in der die Daten gelesen werden, eine Wartezeit (Metronom 100ms) enthalten ist, dann ist das hier auch nicht falsch, aber unnötig und für mich ein zuverlässiges Indiz dafür, daß der betreffende Programmierer nicht richtig verstanden hat wie das Lesen der Daten funktioniert.

Also: Das Lese-VI liest die am Eingang konfigurierte "Anzahl von Samples pro Kanal" aus dem Lesepuffer aus. Die Regel ist allerdings eher, daß diese Anzahl, wenn das VI aufgerufen wird, noch nicht im Buffer ist. Dann wartet das VI geduldig (max. bis zum Timeout) bis der Buffer bis zu dieser Anzahl aufgefüllt ist. Bei Wiederholung diese Vorganges in einer while-Schleife synchronisiert sich die Schleife damit von selbst, es können, auf Dauer gesehen, nicht mehr und nicht weniger Samples gelesen werden, als bei der kontinuierlichen Datenerfassung anfallen.

Hier ist es so: Anzahl der Samples ist mit Samplerate fest verbunden --> Buffer auffüllen dauert genau 1 sec, bei Rate=2000 werden immer 2000 Samples pro Kanal gelesen. Soweit OK.

Funktionsprüfung ergab: Die Schleife wird nach dem 2. Durchlauf beendet, ob gewollt oder nicht, die Task wird gestoppt. auch OK.

Schwierigkeiten können entstehen, wenn das, was in der Schleife sonst noch gemacht wird, länger als 1 sec dauert. Dann kommt es zum Bufferüberlauf und damit genau zu der von dir berichteten Fehlermeldung.


NB: Ein Ereignisknoten befindet sich in der Regel immer in einer While-Schliefe, das ist bei Dir nicht der Fall. Nach dem Auslösen eines Ereignisses wird das ganze Programm beendet. Ist das so gewollt?

' schrieb:Funktionsprüfung ergab: Die Schleife wird nach dem 2. Durchlauf beendet, ob gewollt oder nicht, die Task wird gestoppt. auch OK.

...das ist gewollt, die Durchläufe kann man mit 'Messzeit' auf dem FP erhöhen.

' schrieb:NB: Ein Ereignisknoten befindet sich in der Regel immer in einer While-Schliefe, das ist bei Dir nicht der Fall. Nach dem Auslösen eines Ereignisses wird das ganze Programm beendet. Ist das so gewollt?

...worauf spielst du an?

' schrieb:...das ist gewollt, die Durchläufe kann man mit 'Messzeit' auf dem FP erhöhen.
...worauf spielst du an?

Habe mir alles noch mal angesehen. Diagnose: Es ist völlig klar, daß das Programm nur eine gewisse Zeit stabil läuft, das hat aber nur indirekt mit der Datenerfassung etwas zu tun.
Das Anfügen immer neuer Elemente an einen Array-Struktur in einer Schleife erfordert bei jedem Durchlauf eine Reorganisation des Speichers. Bei großen Datenmengen ist von dieser Methode, wie Du sie hier praktiziert, dringend abzuraten. Nach 300sec hast Du 2000*4*300 Datenelemente, die alle Sekunden zu reorganisieren sind. Offenbar reicht diese Sekunde dann nicht mehr aus, die Schleife braucht für einen Durchlauf länger als eine Sekunde, und damit kommt es zum Überlauf des Datenpuffers.

Ereignisstruktur: Sie wird hier pro Programmstart nur ein einziges Mal ausgeführt wird und dann nie wieder. Das mag OK sein oder auch nicht, worauf ich mit meiner Anmerkung "hinaus will" ist, daß Du das wissen solltest.

Visualisieren heiß für mich Daten zu einer verwertbaren Aussage zu verdichten. Millionen von Datenpunkten in ein Diagramm mit höchstens 1000 x-Pixeln hineinzuschmeißen macht hingegen überhaupt keinen vernünftigen Sinn.

HI,
...was würde denn deiner Meinung nach Sinn machen? Das Problem ist, ich muss die Signale im xy-Graph darstellen, da ich unbedingt die Cursor brauche.
Gruß

' schrieb:...was würde denn deiner Meinung nach Sinn machen? Das Problem ist, ich muss die Signale im xy-Graph darstellen, da ich unbedingt die Cursor brauche.
Gruß

Wie kommst Du denn darauf, daß Du mit einer Strip Card /einem Sigalverlsaufsdiagramm keine oder weniger Möglichkeiten bei der Verwendung von Cursoren hast? Alles, was sich mit Cursoren machen läßt, geht doch da mindestens genau so gut.
Habe mal auf die Schnelle die XY-Plots ersetzt und außerdem alle Hin/Rückverwandlungen dynamischer Signale entfernt. Das VI ist aber von einem ausgereiften Zustand immer noch meilenweit entfernt, die Änderungen sollen nur Anregungen geben. Man beachte, daß jetzt die Signalnamen richtig an die Plots übergeben werden.
Durch die Historienlänge ist die Ansammlung von Daten beschränkt, es kann also nicht mehr zum Aussteigen des Programms wegen Datenüberlauf kommen.