DAQmx Fehler -200279, von Puffern und schritthaltenden Erfassungen

Hallo liebes LabVIEWForum,

heute habe ich mir ein wenig Zeit genommen, mich etwas mit den Puffern der DAQmx-Treiber zu beschäftigen. Dazu habe ich mir das Beispiel-VI zur kontinuierlichen Spannungserfassung geschnappt, Puffergrößen manuell geschrieben und gelesen und in der Schleife, in der ausgelesen wird, ein Element zur Verzögerung eingesetzt um den Treiber ein bisschen zu piksen.

Mein Grundverständnis ist aktuell folgendes: Die wichtigste Größe bezüglich des Kanals ist die "Abtastrate", hier im Beispiel-VI "Sample-Rate" genannt.
Dann gibt es auf der Oberfläche des Beispiel-VIs noch "Sample-Anzahl", das "DAQmx - Timing"-VI nennt es "Samples pro Kanal" und das bestimmt, wie viele Datenpunkte die Schleife pro Durchlauf entnimmt. Daraus lassen sich dann auch mit "Abtastrate" / "Samples pro Kanal" = "Auslesungen pro Sekunde" ableiten. Zumindest nach meinem Verständnis.

Wähle ich also 100000 S/s (Samples pro Sekunde) als Abtastrate und 100000 S als Sample-Anzahl ergibt sich für mich eine Auslesung pro Sekunde.

Das funktioniert auch. Soweit so gut; wer hätte damit gerechnet. Der DAQmx Treiber verwendet in diesem Fall automatisch die "Samples pro Kanal" als Puffergröße; macht ja auch Sinn; das Programm wartet, bis der Puffer voll ist und entnimmt dann die Daten.

Wenn ich jetzt den Puffer über die Eigenschaftsknoten auf 110000 S einstelle, funktioniert die Datenerfassung immernoch. Auch soweit so klar. Stelle ich den Puffer auf 10 S ein, gibt es einen -200279 und das ist nachvollziehbar. Stelle ich aber 50000 S, läuft das VI wunderbar... und das ist der Punkt, den ich nicht verstehe. Wenn "DAQmx - Lesen" auf 100000 S wartet... das muss doch sofort einen Fehler geben. Warum funktioniert das?

Bei einem anderen Experiment verzögere ich die Schleife solange, bis der "DAQmx - Lesen" nicht mehr rechtzeitig zum Auslesen aufgerufen wird. Mein Rechner kommt beispielsweise mit einer Verzögerung von 0,998 s noch gut zurecht. Bei 0,999 s halt irgendwann nicht mehr. Erhöht man den Puffer auf 200000 S, läuft das VI mit 0,999 s Verzögerung noch eine muntere Viertelstunde und das ist auch nachvollziehbar.

Nun, warum ich das mache? Meine Programme erfassen Daten teilweise über Tage problemlos. Der Rechner sperrt sich nach einer Weile und dann kommt es vor, dass ich mich anmelde und vor einem -200279 stehe, was sehr frustrierend ist. Im Log stelle ich dann fest, dass tatsächlich das Entsperren des Rechners es zum Fehler hat kommen lassen. Bis dahin lief alles fehlerfrei. Ein solcher Fehler ließe sich vermutlich schon mit dem Erhöhen des Puffers verhältnismäßig gut abfangen. Wie macht ihr das? Ist euch das Verhalten schoneinmal aufgefallen? Und was verstehe ich im Puffer-konzept nicht, dass ich mich wundere, dass die Datenerfassung mit halbem Puffer läuft?

mit Gruß
stoa

Anzeige

Hallo stoa,

Zitat:Stelle ich aber 50000 S, läuft das VI wunderbar... und das ist der Punkt, den ich nicht verstehe. Wenn "DAQmx - Lesen" auf 100000 S wartet... das muss doch sofort einen Fehler geben. Warum funktioniert das?

Hilfe zu DAQmxTiming öffnen, dann die Erläuterung zu "Samples pro Kanal" lesen, dann dem Link zu "Bestimmung der Puffergröße" folgen, weiterlesen…

Zitat:Nun, warum ich das mache? Meine Programme erfassen Daten teilweise über Tage problemlos. Der Rechner sperrt sich nach einer Weile und dann kommt es vor, dass ich mich anmelde und vor einem -200279 stehe, was sehr frustrierend ist. Im Log stelle ich dann fest, dass tatsächlich das Entsperren des Rechners es zum Fehler hat kommen lassen. Bis dahin lief alles fehlerfrei. Ein solcher Fehler ließe sich vermutlich schon mit dem Erhöhen des Puffers verhältnismäßig gut abfangen. Wie macht ihr das?

Ich löse dass, indem Messrechner von der Firmen-IT auf "Sonderstatus" gesetzt werden und sich niemals von allein sperren (d.h. Screensaver ist deaktiviert)!
Oder du nimmst ein Nicht-Windows-System (wie cRIO), wenn du Messungen 24/7 laufen lassen willst…

Merke: Windows ist keine Plattform, die auf "dauerhafte Zuverlässigkeit" ausgelegt ist.

Hallo GerdW,

Zitat:
Hilfe zu DAQmxTiming öffnen, dann die Erläuterung zu "Samples pro Kanal" lesen, dann dem Link zu "Bestimmung der Puffergröße" folgen, weiterlesen…

Danke für den Hinweis. Die Hilfe dazu kenne ich. Dort heißt es:

Zitat:Wenn Sie den Sample-Modus der Funktion/des VIs "Timing" Ihrer Datenerfassung auf "Kontinuierlich" setzen, wird für NI-DAQmx ein Puffer reserviert, dessen Größe dem Attribut/der Eigenschaft "Samples pro Kanal" entspricht – es sei denn, der Wert ist kleiner als der in der nachfolgenden Tabelle aufgeführte. Ist der Wert von Samples pro Kanal kleiner, wird in NI-DAQmx der Wert aus der Tabelle verwendet.

Sample-Rate Puffergröße
keine Angabe 10 kS
0–100 S/s 1 kS
101–10,000 S/s 10 kS
10,001–1,000,000 S/s 100 kS
>1.000.000 S/s 1 MS

Auch, wenn es an dieser Stelle etwas unverständlich formuliert ist, ist das schon in Ordnung so, nur beantwortet es nicht meine Frage. In meinem Beispiel habe ich eine Abtastrate von 100000 S/s und "Samples pro Kanal" von 100000 S. Dann setze ich die Puffergröße manuell auf 50000 S und das funktioniert. Das sollte es jedoch nicht; ich erhalte einmal pro Sekunde 100000 Werte. Schraube ich den Puffer weiter runter, auf 50 S beispielsweise, bekomme ich 100000 Werte, die fehlerhaft sind und eine Fehlermeldung. Das passt doch nicht zusammen, oder?

Was Windows angeht. Ja. Stimmt schon, ist doof. Früher oder später wird das vermutlich ohnehin cRIO. Nur bis dahin... die IT knirscht mit den Zähnen, wenn ich da einen Sonderstatus erzielen will, aber die knirschen ohnehin den ganzen Tag. Vielleicht spreche ich das mal an. Ansonsten scheint das Vergrößern des Puffers tatsächlich Abhilfe zu schaffen beim Entsperren.

mit Gruß
stoa

Hallo stoa,

Zitat:In meinem Beispiel habe ich eine Abtastrate von 100000 S/s und "Samples pro Kanal" von 100000 S. Dann setze ich die Puffergröße manuell auf 50000 S und das funktioniert. Das sollte es jedoch nicht; ich erhalte einmal pro Sekunde 100000 Werte.

Laut Hilfe sollte DAQmx dann einfach weiter einen Puffer von 100kSamples benutzen!
Außerdem funktioniert es ja durchaus, wenn der Puffer kleiner ist als Samplerate*1s, wie die Tabelle zeigt: auch bei 1MS/s wird ein Puffer von 100kS verwendet…

Zitat:Schraube ich den Puffer weiter runter, auf 50 S beispielsweise, bekomme ich 100000 Werte, die fehlerhaft sind und eine Fehlermeldung. Das passt doch nicht zusammen, oder?

Das sollte laut Hilfe nicht passieren, da ja die Mindestgröße laut Tabelle benutzt werden sollte.
Allerdings gehört der Programmierer schon bestraft, wenn er solch unsinnige Werte anfordert!

(23.02.2021 13:05 )stoa schrieb:  Stelle ich aber 50000 S, läuft das VI wunderbar... und das ist der Punkt, den ich nicht verstehe. Wenn "DAQmx - Lesen" auf 100000 S wartet... das muss doch sofort einen Fehler geben. Warum funktioniert das?

Der Puffer ist vor allem dazu da um Daten aufzunehmen während das Programm gerade nicht beim auslesen von Daten ist. Oder anders herum: Noch bevor die 50000 Samples den Puffer gefüllt haben, ist dein Programm wieder beim auslesen der Daten und es kann nicht mehr viel passieren, denn das Daten auslesen geht schneller als das schreiben neuer Daten in den Puffer (außer bei extrem hohen Sampleraten oder einem extrem lahmen PC).

Zitat:

Zitat:In meinem Beispiel habe ich eine Abtastrate von 100000 S/s und "Samples pro Kanal" von 100000 S. Dann setze ich die Puffergröße manuell auf 50000 S und das funktioniert. Das sollte es jedoch nicht; ich erhalte einmal pro Sekunde 100000 Werte.

Laut Hilfe sollte DAQmx dann einfach weiter einen Puffer von 100kSamples benutzen!
Außerdem funktioniert es ja durchaus, wenn der Puffer kleiner ist als Samplerate*1s, wie die Tabelle zeigt: auch bei 1MS/s wird ein Puffer von 100kS verwendet…

Ja, richtig. Aber das scheint nicht zu passieren, denn erstens zeigt mir der Eigenschaftsknoten den Puffer an, den ich eingestellt habe und zweitens kann ich damit einen Fehler provozieren, sobald ich den Puffer klein genug wähle.

Zitat:Das sollte laut Hilfe nicht passieren, da ja die Mindestgröße laut Tabelle benutzt werden sollte.
Allerdings gehört der Programmierer schon bestraft, wenn er solch unsinnige Werte anfordert!

Sicher, sinnvoll ist das nicht, nur war das schließlich zum Ausprobieren. Und es hat schon etwas gebracht, wie man sieht.

Zitat:Der Puffer ist vor allem dazu da um Daten aufzunehmen während das Programm gerade nicht beim auslesen von Daten ist. Oder anders herum: Noch bevor die 50000 Samples den Puffer gefüllt haben, ist dein Programm wieder beim auslesen der Daten und es kann nicht mehr viel passieren, denn das Daten auslesen geht schneller als das schreiben neuer Daten in den Puffer (außer bei extrem hohen Sampleraten oder einem extrem lahmen PC).

Hallo Martin.Henz, schön dass du dich beteiligst. Ja, grundsätzlich funktioniert das mit den Puffern schon so, die können etwas größer sein oder etwas kleiner, je nach Anwendung. Nur so wie ich die DAQmx-Treiber verstehe, liest "DAQmx - Lesen" die Werte aus, wenn der Puffer mindestens die erwartete Anzahl an Datenpunkte enthält. Solange wartet das VI. Bei zu kleinen Puffern, müsste es dann einen Fehler geben. Bei meinen Tests entnimmt das VI einmal pro Sekunde 100000 Werte aus einem Puffer, der nur 50000 Werte groß ist. Stellt man den Puffer auf 10 Werte, entnimmt das VI 100000 Werte aus diesem Puffer und man erkennt am Graphen, dass das nicht die gleichen 100000 Werte sind, wie bei einem größeren Puffer. Und das ist irgendwie ganz schön unstimmig.

Anzeige

Hallo stoa,

irgendwelche abtrakten und vereinfachten Beschreibungen sind eher selten exakt richtig.

Beispieleinstellungen:
Wartezeit = 0,4s, Puffergröße = 500, Sample Rate = 1000, Sample Anzahl = 2000

Theoretisch steckt dein Programm nun etwas weniger als 1,6 Sekunden beim Datenlesen fest. Das macht es auch.

Nun nutzt du diese 1,6 Sekunden und fragst das "DAQmx Read" Property "Available Samples per Channel" ab.

Als erstes fragst du es unmittelbar vor dem auslesen der Daten ab. Da stecken dann etwas mehr als 400 Samples im Puffer, weil 400ms lang gewartet wurde).
Während dem auslesen fragst du nun z.B. nach 100ms dieses Property ab und nach 300ms usw...

Das sollte zeigen, was da weiter unten im Treiber so in etwa passiert.

Halll Martin.Henz,

das sieht schon interessant aus und "Verfügbare Samples Pro Kanal" ist auch ziemlich nützlich.

Zitat:Beispieleinstellungen:
Wartezeit = 0,4s, Puffergröße = 500, Sample Rate = 1000, Sample Anzahl = 2000

So bekomme ich es leider nicht an's Laufen. Das gibt sofort -200279 und die 400 Samples im Puffer kriege ich nicht zu Gesicht, wie ich mich auch winde. Lädst du dein VI hoch mit dem 500er Puffer, das funktioniert hat?

Anbei mein VI mit meinen Werten als Standard. Dort mit einem 2000er Puffer. Gut zu erkennen ist da, dass zu Beginn keine Werte im Puffer sind, dieser sich alle 100 ms mit 100 Werten füllt und im zweiten Durchlauf der erste gelesene Wert der letzte vom vorherigen Durchflauf war - soweit klar, denn dazwischen passiert nichts. Wenn ich jetzt jedoch die zu wartende Zeit erhöhe und das länger andauern lasse, als das Prüfen der verfügbaren Samples, bleibt der erste Wert im folgenden Durchlauf gleich dem letzten Wert im vorherigen Durchlauf. Und das dürfte nicht passieren. Der Wert müsste zirka 1000*Zeit[s] von der zu wartenden Zeit sein. Ist sie aber nicht. Und das bedeutet unter anderem, dass ich immer noch nicht verstehe, wie der Treiber funktioniert und dieser mit dem Puffer umgeht. Kannst du mir das genauer erklären? Oder weiß sonst jemand Rat?

mit Gruß
stoa

Hallo stoa,

moment mal, hast du die Hilfe zu dieser PropertyNode durchgelesen, die du da setzt? Du hebelst die Automatik von DAQmx gnadenlos aus.

   

Zitat:Input:Buffer Size Property
Short Name: Input.BufSize

Property of DAQmx Buffer

Specifies the number of samples the input buffer can hold for each channel in the task. Zero indicates to allocate no buffer. Use a buffer size of 0 to perform a hardware-timed operation without using a buffer. Setting this property overrides the automatic input buffer allocation that NI-DAQmx performs.

D.h. bei Size=10 ist der Buffer natürlich VIEL zu klein, damit die Daten noch von der Karte an den RAM übertragen werden können, bei den gewünschten Erfassungsraten von 100 kS/s.

Vgl. auch hier:
https://zone.ni.com/reference/en-XX/help...ntcacqgen/

Bei den Einstellungen, die Fehler schmeißen, schafft es der DAQmx-Treiber nicht, die kleinen Pakete häufig genug an den RAM zu übertragen.

Gruß, Jens

EDIT & P.S.: Die Datenbus-Anbindung der Karte scheint übrigens eine Rolle zu spielen. Mit einer simulierten PCIe-6351 läuft das Bsp auch bei Input.Buffer=10, bei einer simulierten PCI-6221 kommt gleich ein Fehler.

(23.02.2021 13:05 )stoa schrieb:  Wähle ich also 100000 S/s (Samples pro Sekunde) als Abtastrate und 100000 S als Sample-Anzahl ergibt sich für mich eine Auslesung pro Sekunde

Auch wenn sich eine Auslesung pro Sekunde ergibt, so muss du auch in diesem Falle nicht zwangsweise genau 1 Mal auslesen. Auch hier kannst du z.B. 20 Mal auslesen.

So mach ich das mit dem Erfassen von Daten:
* Einfach im Raster von (z.B.) 50ms alle vorliegenden Samples per DAQmx-Read einlesen und in einem eigenen Puffer sammeln.

Dieses Verfahren ist von der Sample-Rate und eigentlich auch von der Puffergröße, von der du spricht, unabhängig. Ich stelle die Puffergröße einfach auf das 10-fache der Anzahl pro 50ms ein. Mit dieser Puffergröße (wahrscheinlich reicht auch schon dreimal) kannst du alle zeitlichen Schwankungen, ob von Windows, LV oder dem DAQmx, handhaben.