Hi
ich hab ein Problem bei der Simulation eines
http://sine.ni.com/nips/cds/view/p/lang/de/nid/201987
Ich habe mein VI zusätzlich angehängt und ein Screenshot. Was es macht: Die Hardware NI USB 6009 wird durch einen 6221 simuliert, dieser hat 8 Signale. Ich möchte das Signal 0 (Startschuss) in einem "Buffer" speichern. Dafür wird die Hardware "kontinuierlich" simuliert, also ständig
ein neuer Wert. Diesen hänge ich an "i%size", wobei size die Größe des Arrays / Buffers ist.
Im Frontpanel seht ihr links die aktuell anliegenden Werte aller 8 Signale und rechts meinen Buffer mit der Größe von 30.000.
- Ich habe ihn momentan auf 1kHz, aber ich muss in meinem VI 10.000 Werte lesen, um den Graphen / Sinuskurve komplett zu sehen. Wo kommt der Faktor 10 her? Falls ich bspw. 1000 Werte puffere, ergibt sich das angehängt Bild.
- Auf der NI Seite steth "Abtastrate 48 kS/s" => das bedeutet 48kHz?
- Wenn ich mein VI mit 30.000 starte, dann stürzt er zum Schluss mit folgendem Fehler ab:
Fehler -200279 ist bei DAQmx Read (Analog 1D DBL NChan 1Samp).vi:1 aufgetreten
Mögliche Ursachen:
Measurements: Es wurde versucht Abtastwerte zu lesen, die nicht mehr zur Verfügung stehen. Der angeforderte Abtastwert war zuvor verfügbar, wurde jedoch überschrieben.
Vergrößern des Puffers, häufigeres Lesen der Daten oder Angabe einer festen Anzahl zu lesender Abtastwerte anstatt alle verfügbaren Abtastwerte zu lesen, könnte das Problem eventuell beheben.
Eigenschaft: RelativZu
Zugehöriger Wert: Aktuelle Leseposition
Eigenschaft: Offset
Zugehöriger Wert:
Task-Name: SpannungTask_6221
Ich verstehe das nicht. Ich fülle mein Array doch unabhängig von der Samplerate und ich lese aus dem Fehler, dass ich mehr lesen möchte als die Samplerate hergibt. Der Fehler taucht auch bei 28.000, aber bisher bei keinem Wert kleiner als 25.000. Das VI läuft bei 18.000 nun schon eine Weile ohne Fehler durch.
Ich hoffe ihr konntet mir folgen und wisst Antworten.
Danke
mfg
Ein paar Hinweise allgemeiner Art:
1. Wenn du mit der 6009 8 analoge Kanäle erfassen willst, dann geht das nicht im differentiellen Modus, sondern nur RSE oder NRSE, d.h. die Masse aller Signale muss gleich sein.
2. Die bei den Messkarten angegebene Samplerate bezieht sich (fast) immer auf die Gesamtrate alle Kanäle zusammen. Somit hast du bei der 6009 und 8 Kanälen maximal 48kS/s geteilt 8, also 6kHz zu erwarten, wahrscheinlich sogar etwas weniger.
3. Dein VI wäre einfacher zu analysieren, wenn du statt des Spannungstasks den entsprechenden DAQmx Code oder ein SubVI einfügen würdest. Dazu einfach Recher Maus-Klick auf Task->Create DAQmx-Code (Configuration müsste langen).
MfG, Jens
' schrieb:1. Wenn du mit der 6009 8 analoge Kanäle erfassen willst, dann geht das nicht im differentiellen Modus, sondern nur RSE oder NRSE, d.h. die Masse aller Signale muss gleich sein.
2. Die bei den Messkarten angegebene Samplerate bezieht sich (fast) immer auf die Gesamtrate alle Kanäle zusammen. Somit hast du bei der 6009 und 8 Kanälen maximal 48kS/s geteilt 8, also 6kHz zu erwarten, wahrscheinlich sogar etwas weniger.
3. Dein VI wäre einfacher zu analysieren, wenn du statt des Spannungstasks den entsprechenden DAQmx Code oder ein SubVI einfügen würdest. Dazu einfach Recher Maus-Klick auf Task->Create DAQmx-Code (Configuration müsste langen).
1. Danke, geändert auf RSE.
2. Erfassungsmodus mit 6kHz
3. Reicht der Anhang? Nun tritt der Fehler aber bereits bei 15.000 auf. Womöglich wegen der geänderten Samplerate. Dennoch verstehe ich ihn nicht.
Ah ja, jetzt wird es schon etwas besser, wobei, bei mir läuft das durch ohne Fehlermeldung. Trotzdem ist das Ganze nicht sonderlich gut.
Ist dir eigentlich klar, was du da eingestellt/programmiert hast? Du hast eine kontinuierliche Datenerfassung von 8 analogen Kanälen mit der höchstmöglichen Datenrate der USB-6009, nämlich 48kS/s. Dabei hast du den FIFO-Buffer auf 100 Samples gestellt. Diese Einstellung wird aber standardmäßig durch einen viel größeren Buffer ersetzt (
http://www.LabVIEWforum.de/index.php?s=&am...ost&p=43731).
In deiner Leseschleife liest du jetzt aber immer nur einen Wert aus, wobei der Buffer aber mit 6kHz vollgeschrieben wird. Da muss ein etwas langsamerer Rechner ja irgendwann nicht mehr mitkommen. Folge, der Buffer wird überschrieben.
Lösung: Pro Schleife mehr Werte auf einmal auslesen, z.B. wenigstens 50 oder 100, die Prozessorlast geht dramatisch runter und du solltest keinen Ärger mit dem Buffer haben.
MfG, Jens
Ich verstehe deine Antwort noch nicht ganz:
' schrieb:Du hast eine kontinuierliche Datenerfassung von 8 analogen Kanälen mit der höchstmöglichen Datenrate der USB-6009, nämlich 48kS/s.
Das meinst du wegen der MAX Einstellung oder sieht man das auch im VI? Die Aussage klingt so negativ wegen "höchstmöglich".
' schrieb:Dabei hast du den FIFO-Buffer auf 100 Samples gestellt.
Du meinst "Zu lesende Samples" im MAX Task? Was für ein Puffer soll das sein? Wird hier ein hardwareseitiger Puffer simuliert? Ich habe mir darüber keine Gedanken mehr gemacht, weil er meiner Meinung nach nicht mehr wichtig ist, sobald ich einzelne Samples anstatt mehrerer im VI lese. Bleibt er dennoch wichtig? Bzw. du meinst ja, dass LV den sowieso mit 1.000 überschreibt? (Laut der Tabelle in deinem Link.)
' schrieb:In deiner Leseschleife liest du jetzt aber immer nur einen Wert aus, wobei der Buffer aber mit 6kHz vollgeschrieben wird.
Hier meinst du den FIFO-Buffer von eben? Er würde also 1000 anstatt 100 Samples fassen. Lass ich ihn mit 6kHz vollschreiben, heißt das, ich müsste ihn 6x pro Sekunde komplett gelesen haben. Korrekt so? Und wenn ein Rechner das nicht mehr simulieren kann, weil die CPU Last zu hoch ist, schaff ich bspw nur noch 5x pro Sekunde komplett zu lesen und er überschreibt das 6. Mal und wirf daraufhin einen Fehler?
' schrieb:Lösung: Pro Schleife mehr Werte auf einmal auslesen, z.B. wenigstens 50 oder 100, die Prozessorlast geht dramatisch runter und du solltest keinen Ärger mit dem Buffer haben.
Das würde jetzt bei mir bedeuten, dass ich eine for-Schleife von 50-100 um "Analog 1D DBL NKanal 1Abtastung" herum setze?
//edit
Meine letzte Vermutung glaube ich nun nicht mehr, da du
http://www.LabVIEWforum.de/index.php?showt...ost&p=43420 hier auch keine for Schleife in meinem Sinn darum hast und es läuft bei mir mit 6.000 kHz Samplerate und 100 sowie 1000 Buffersize. Umso mehr verstehe ich dann deinen Vorschlag mit der for Schleife nicht.
//edit2
Falls es noch nicht so klar geworden ist, wollte ich es einmal genau erwähnen: Ich möchte exakt 1s puffern, da dort alles wichtige passiert. Mehr ist auch nicht schlimm, aber unnötig.
Ein paar Antworten:
Ja, man sieht am SubVI, dass du 8 AI hast. Und das mit höchstmöglich soll nur darauf hindeuten, dass die USB-6009 halt nicht mehr als 48kS/s (aggregate) kann.
Der Anschluß "zu lesende Samples" ist beim Modus "kontinuierlich" die Größe eines im RAM des Computers erzeugten FIFO-Buffers (wird durch den DAQmx erzeugt, hat von der Seite her nichts mit einem Hardware-Buffer - z.B. auf der Messkarte selber - zu tun). Um die genaue Größe braucht man sich eigentlich nicht zu kümmern.
Den FIFO-Buffer braucht man nicht komplett vollschreiben lassen, bevor man ihn ausliest. Würde ich sogar dringend davon abraten, dann kommt es eben zu solchen Überläufen.
Und nein, ich meine nicht, noch eine zusätzliche FOR-Schleife einbauen, sondern einen anderen Modus des Read-VI zu verwenden, z.B. Analog 1D DBL NKanal NAbtastung.
Und was meinst du jetzt mit genau 1s puffern? Das ist mir nicht klar? Willst du nur eine Sekunde messen? Wieso dann der kontinuierlich-Modus?
MfG, Jens
EDIT: Noch mal zur Klarstellung: Wieso bekommst du irgendwann eine Fehlermeldung: LV richtet eine FIFO-Buffer ein. Der wird durch die Einstellungen des AI-Tasks mit einer Rate von 6 kHz beschrieben. Damit es auf Dauer zu keinem Buffer-Overflow kommt, musst du also auch im Schnitt soviele Dateien aus dem Buffer wieder rausholen (über das Read-VI). Wenn du in jedem Durchlauf aber nur einen Datensatz abholst, muss die While-Schleife ebenfalls mit 6 kHz laufen. Das dürfte dann irgendwann zum Überlauf führen.
' schrieb:Und nein, ich meine nicht, noch eine zusätzliche FOR-Schleife einbauen, sondern einen anderen Modus des Read-VI zu verwenden, z.B. Analog 1D DBL NKanal NAbtastung.
Und was meinst du jetzt mit genau 1s puffern? Das ist mir nicht klar? Willst du nur eine Sekunde messen? Wieso dann der kontinuierlich-Modus?
Ich möchte den NI USB 6009 mit dem 6221 simulieren. Um das am nächsten zur tatsächlichen Hardware zu tun, bin ich auf kontinuierlich gegangen, da ich glaube, dass die Hardware auch immer nur einen Wert pro Kanal schickt und nicht bereits auf N Samples gepuffert.
Dann interessiert mich aber stets nur eine Sekunde vom Signal AI0.
0s bis 1s
0.1s bis 1.1s
0.2s bis 1.2s
...
Ich suche in der einen Sekunde, ob / wo ein Peak auftritt und vom Peak +/- 500ms sollten die komplette Sequenz beinhalten, die ich benötige. Wenn ich den Peak erkannt habe, möchte ich eben dann diese Sekunde weiterschicken, dafür muss ich es ja puffern.
Wenn ich auf analog 1D DBL NKanal 1Abtastung umsteige, kommt der Fehler immernoch.
Ich wüsste nicht wie ich der while Schleife sage, dass sie "schneller" / mit einer Frequenz arbeiten soll. Ich hab das Read.vi so verstanden, dass er liest, sobald etwas da ist.
Zitat:Ich möchte den NI USB 6009 mit dem 6221 simulieren.
Das weiss ich auch, dazu habe u.a. ich dir in deinem anderen Thread geraten
Zitat:Um das am nächsten zur tatsächlichen Hardware zu tun, bin ich auf kontinuierlich gegangen, da ich glaube, dass die Hardware auch immer nur einen Wert pro Kanal schickt und nicht bereits auf N Samples gepuffert.
Meinst du jetzt damit, das die DAQ-Karte im Round Robin Verfahren abscannt, sprich jeweils einen Wert pro Kanal und dann wieder von vorne anfängt? Ja, damit hast du recht, das heisst aber nicht, dass der DAQmx-Treiber diese Werte nicht trotzdem schön brav Kanalweise in einem FIFO-Puffer vorhält, bis du sie abholst. Du kannst also auch mehrere Samples in einem Vorgang abholen.
Zitat:Dann interessiert mich aber stets nur eine Sekunde vom Signal AI0.
0s bis 1s
0.1s bis 1.1s
0.2s bis 1.2s
...
Ich suche in der einen Sekunde, ob / wo ein Peak auftritt und vom Peak +/- 500ms sollten die komplette Sequenz beinhalten, die ich benötige. Wenn ich den Peak erkannt habe, möchte ich eben dann diese Sekunde weiterschicken, dafür muss ich es ja puffern.
Wenn ich auf analog 1D DBL NKanal 1Abtastung umsteige, kommt der Fehler immernoch.
Ich habe übrigens N Abtastungen geschrieben, nicht eine Abtastung. Habe mich nur bei dem 1D vertan, hätte natürlich 2D DBL NKanal NAbtastungen lauten müssen.
Zitat:Ich wüsste nicht wie ich der while Schleife sage, dass sie "schneller" / mit einer Frequenz arbeiten soll. Ich hab das Read.vi so verstanden, dass er liest, sobald etwas da ist.
Ja genau, aber da du immer nur eine Wert (aller 8 Kanäle) aus dem Puffer abholst, und wenn die While-Schleife nicht schnell genug arbeitet (schließlich hat Windows noch was anderes zu tun), dann kann halt der Puffer volllaufen. Und bei den momentanen Einstellungen muss sie mindesten 6000mal pro Sekunde ablaufen, da geht die Prozessorlast halt ganz schön rauf. Besser ist es, in einem Rutsch z.B. mindestens 100 Samples abzuholen, dann muss die While-Schleife nur 60mal pro Sekunde ablaufen.
Das geht z.B so:
[
attachment=11167]
Das SubVI DAQmxCode6221.vi ist dasselbe wie aus deinem Beitrag.
Schau dir vielleicht auch mal das Beispiel "Cont Acq&Graph Voltage-Analog SW Trigger.vi" aus dem NI-Examplefinder an.
MfG, Jens
Ok, also mit NKanäle und NSamples (bspw 100 Samples) geht es. Und so etwas ist auch sehr realitätsnah, wenn ich direkt die Hardwarekomponente dran habe? Dass ich auch bspw 100 Samples gepuffert bereits bekomme bzw. softwareseitig von LV gestellt bekomme?
Und wieso bekomme ich bei deinem "Cont Acq&Graph Voltage-Analog SW Trigger.vi" Beispiel mit 1 samples per channel keinen Fehler? Weil nur ein Kanal simuliert wird?
' schrieb:Ok, also mit NKanäle und NSamples (bspw 100 Samples) geht es. Und so etwas ist auch sehr realitätsnah, wenn ich direkt die Hardwarekomponente dran habe? Dass ich auch bspw 100 Samples gepuffert bereits bekomme bzw. softwareseitig von LV gestellt bekomme?
Wieso sollte das nicht realitätsnah sein?
' schrieb:Und wieso bekomme ich bei deinem "Cont Acq&Graph Voltage-Analog SW Trigger.vi" Beispiel mit 1 samples per channel keinen Fehler? Weil nur ein Kanal simuliert wird?
Das ist wahrscheinlich einer der Gründe.
Dann hätten wir noch: Das genannte Beispiel zeichnet nicht dauernd den Graphen im Frontpanel neu, sondern ja erst, wenn der Trigger-Fall eingetreten ist. In deinem ersten Beispiel-VI hast du ja auch noch dauernd (sprich nach jedem Auslesen eines Wertes) 2 Graphen auf dem Frontpanel neu gezeichnet. Das hat noch viel mehr Rechenzeit geschluckt als das Auslesen der Daten selber. (Sorry, das hätte ich auch gleich erwähnen sollen).
MfG, Jens