Vergrößern des Puffers

Hallo,

ich bekomme folgende Fehlermeldung:

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.

Wie vergrößere ich denn den Puffer?

Danke schonmal,
Andreas

Anzeige

Guck dir mal im MAX die Einstellungen deines Tasks an, da erscheint bei jedem Parameter ne Hilfe im rechten Feld, wenn du mit der Maus über drüber fährst!

Allerdings gibts auch unter Start >> Programme >> National Instruments >> NI-DAQ >> Hilfe für DAQmx weitere Informationen. Da steht dann auch, dass du bei ner kontinuierlichen Messung keinen Einfluss auf die Puffergröße hast, das regelt der DAQmx-Treiber für dich. Dir bleibt nur die Möglichkeit, langsamer abzutasten und/oder pro Aufruf mehr Werte aus dem Puffer zu lesen.

Hallo ich häng mich einfach mal an den Beitrag weil ich die gleiche Fehlermeldung habe.

Auf der andern Seite glaube ich nicht das es bei mir wirklich an der Puffergröße liegt.
Ich versuche für einen Gerätetest nacheinander unterschiedliche analoge Signale über den DAX Assi auszugeben.

Sprich:
Ich übertrage Einstellungen an mein Gerät. Gebe dann ein Signal aus. Danach bewerte ich meine Messergebnisse und starte in einer Schleife den nächsten Test in dem ich die Neuen Einstellungen an das Gerät übertrage.
Soweit funktioniert das auch nur wenn ich nun dem DAX Assi die nächsten Werte übergebe kommt besagte Fehlermeldung.

Also scheint der Assistent den Puffer noch mit den Daten der vorgänger Messung voll zuhaben?
Hat jemand eine idee wie ich den Assistenten von Messung zu Messung wieder in den Grundzustand versetzen kann?

Achso ich Benutze LabVIEW 8.2 und ich fürchte das mein Programm etwas zu umfangreich ist um es hochzuladen

Schon mal Danke

Hallo

Ok ich hab es hin bekommen ich kann mein VI nun beliebig oft hintereinander Starten ohne ein Problem mit dem Puffer zu bekommen. Dafür war es erforderlich den DAQ Assi von kontinuierlich auf n Sampels um zuschalten.

Warum es beim kontinuierlichen Signal nicht geht weis ich aber immer noch nicht? Vielleicht wird der Ringspeicher bei einem wiederholten aufruf nicht neu initalisiert?

Ich wünsch euch noch einen schönen Tag
Movie

Hallo Movie,

ich hätte Dir vorgeschlagen, den DAQ Assistenten rauszuwerfen und die Funktionalität mit DAQmx VI's zu erstellen.
Das ist deutlich flexibler und man hat die volle Kontrolle über den DAQ Task.
Das Assistent ist nett und für einen schnellen Test ok.

Grüße
Andreas

hallo,

also weil das hier nun auch mein problem ist, häng ich mich da einfach mal mit rein ...
wie gesagt, ich habe die gleiche meldung und habe das mit den nsamples auch probiert, aber da treten bei mir lücken im signalverlauf auf und das is nicht so toll. eigentlich will ich auch den DAQ-Assi nicht verwenden; ich habe bis jetzt immer mit den VI s "AI kontinuierlich abtasten" gearbeitet und das ging wunderbar. leider gibts das in meiner neuen version nicht mehr (warum auch immer).
vielleicht ahbe ich auch ein grundsatz-verständnisproblem, weil ich irgendwie nicht weiß wie der das mit der püffergröße und dem ganzen anderen zeugs so meint. hab mir auch mal die tolle hilfe dazu durchgelesen, danach war ich noch verwirrter ...
also wäre schön, wenn mir da mal jemand helfen könnte.

LG

Anzeige

Hallo Cater,

nur schnell ein paar Worte.
Wenn Du die DAQ VI's auf Deinem System nicht findest, solltest Du den DAQmx Treiber mal installieren.

Nun zum Puffer. Ich greife vorerst nur mal zwei Eckpunkte raus.
Wenn Du Deinen DAQ Task konfigurierst und das Timing einstellst, wird dort die Datenerfassungsrate, der Sample-Modus und die Anzahl der Samples pro Kanal eingestellt.

Wählst Du als Sample-Modus "Endliche Anzahl" werden je nach Anzahl der "Samples pro Kanal" Daten erfasst und Dir zur Verfügung gestellt.

Nimmst Du als Sample-Modus "kontinuierlich" verwendet LV die Angabe "Samples pro Kanal" zur Bestimmung der Puffergröße.

Im ersten Fall wird der Fehler nicht auftauchen im zweiten schon eher.
Anhand Deiner Abtastrate erzeugt Deine DAQ Hardware im zweiten Fall kontinuierlich Daten und schreibt diese in den Puffer. Wenn Deine Anwendung nun langsamer die Daten aufarbeitet, als diese erzeugt werden, ist der Puffer irgendwann voll und dann wird die Fehlermeldung ausgegeben, da Daten überschrieben wurden, die Deine Software lesen wollte.
Abhilfe gibt es durch eine geringere Datenerfassungsrate, durch eine schnellere Bearbeitung der Daten oder durch einen größeren Puffer.
Das für und wieder richtet sich nach Deiner Anwendung. Ich hoffe das war verständlich.
Steht übrigens alles in der Hilfe! (Strg+H -> VI DAQmx Timing -> ausführliche Hilfe)

Grüße
Andreas

hallo,

danke erstmal für die erklärung. denke ich hab das jetzt ein bisschen mehr verstanden.
ich hatte zwar schon die hilfe gelesen, aber wirklich schlauer bin ich dadurch nicht geworden.
also wie gesagt, ich habe die DAQmx VI's alle; das ist nicht das problem. in der 8.2er version und in allen davor, gab es bei "Measurement I/O" --> Datenerfassung --> Analogeingang --> Analogeingang Utilitis auch VI's mit denen man die Kanäle abtasten konnte. die vermisse ich etwas, weil ich bis jetzt alles damit gemacht hatte. naja egal.
also wenn ich den puffer größer mache, dann dauert es immer ewig, bis in dem graph irgendwas angezeigt wird. die datenerfassungsrate kann ich nicht kleiner machen, wegen meiner anwendung und das mit der schnelleren bearbeitung ist eigentlich auch nicht realisierbar, glaube ich.
kann man eigentlich irgendwie kontrollieren, wann werte in den puffer geschrieben werden?
ich habe halt den DAQ-Assi in einer Case-struktur drin; sobald sie das erste mal auf TRUE gesetzt wird, werden halt werte übertragen und in dem graph angezeigt. die aufzeichnung wird gestoppt, wenn die Case-struktur FALSE ist. und in der zeit, die vergeht, bis man sie dann das nächste mal wieder "TRUE" setzt, werden halt ständig werte in den puffer geschrieben und der ist dann logischerweise voll. kann man da irgendwas machen? das z.B. keine werte in den puffer geschrieben werden, wenn die Case-struktur FALSE ist? oder dann man vor jedem start der schleife den puffer wieder auf null zetzt oder so was? weil ich will nicht jedesmal das programm beenden müssen nur weil ich die aufzeichnung anhalte. und ich will das ehrlichgesagt nicht mit endlichen werten machen, weil ich dann lücken in der aufzeichnung habe.

LG
Claudi

Hi Cater!

' schrieb:... in der 8.2er version und in allen davor, gab es bei "Measurement I/O" --> Datenerfassung --> Analogeingang --> Analogeingang Utilitis auch VI's mit denen man die Kanäle abtasten konnte. die vermisse ich etwas, weil ich bis jetzt alles damit gemacht hatte. naja egal.

Waren das evtl. VI's vom Traditional DAQ Treiber?
Hört sich zumindest so an.

' schrieb:also wenn ich den puffer größer mache, dann dauert es immer ewig, bis in dem graph irgendwas angezeigt wird.

Das wäre schon der erste Fehler, da die Daten dann den Puffer langsam auffüllen, bis Du sie in FiFo Manier abholst.
Schluß endlich kommt dann der obige Fehler.

' schrieb:kann man eigentlich irgendwie kontrollieren, wann werte in den puffer geschrieben werden?

Da kann man sicher einiges machen, aber wie immer hängt das von der Hardware und von der Messaufgabe ab. Ein paar Infos in diese Richtung wären sicher hilfreich.

' schrieb:kann man da irgendwas machen? das z.B. keine werte in den puffer geschrieben werden, wenn die Case-struktur FALSE ist?

Klar geht das, aber ich vermute nicht mit dem DAQ-Assi.
Schau Dir doch die DAQmx VI's mal an. Die entsprechen sicher denen, mit denen Du früher gearbeitet hast. Damit bist Du deutlich felxibler und kannst einen DAQ-Task auch mal stoppen, damit keine weiteren Daten auflaufen.
Ich mach das in meinen Programm immer, da wo es nötig ist.

Vielleicht kannst Du ja Dein Programm hier ins Forum stellen, dann kann man nach Optimierungen suchen.

Grüße
Andreas

PS: Den DAQ-Assistenten solltest Du aber zuvor eleminieren.

Hi Andreas.

"Waren das evtl. VI's vom Traditional DAQ Treiber?
Hört sich zumindest so an."

nehme ich mal an. die waren jedenfalls ziemlich gut, fand ich bis jetzt immer.

"Das wäre schon der erste Fehler, da die Daten dann den Puffer langsam auffüllen, bis Du sie in FiFo Manier abholst.
Schluß endlich kommt dann der obige Fehler."

wie soll ich denn steuern, dass die daten schneller aufgefüllt werden? was mich daran auch ein bisschen wundert/irritiert: warum bekomme ich dann alle werte vom puffer auf einmal? und warum arbeitet das VI überhaupt, obwohl die Case-Struktur FALSE ist. wenn ich die messung stoppe, ist die Case-Struktur FALSE, warum werden dann trotzdem noch werte in den puffer geschrieben (der DAQ-Assi dürfte doch eigentlich gar nicht mehr laufen)? :angry:das verstehe ich nicht. wenn ich dann ein paar min später die messung wieder starte ist der puffer natürlich voll und dann kommt der fehler, das is ja dann klar. aber wenn ich die messung nach dem stoppen wieder starte will ich ja auch die werte von eben und nicht die von vor 3 min. wahrscheinlich verstehe ich den DAQ-Assi einfach nicht. jedenfalls hatte ich solche probleme mit den anderen VI's nicht.


  vi_mit_DAQ_Assistent.vi (Größe: 200,16 KB / Downloads: 303)


jedenfalls hab ich den DAQ-Assi jetzt rausgeschmissen. hab hier im forum ein VI gefunden, wo die DAQmx VIs verwendet werden. da ich die ja noch nicht kannte, war das schon ne große hilfe. die habe ich, hoffe/glaube ich zumindest jetzt verstanden. also das läuft jetzt erstmal so, wie ich mir das vorgestellt hatte. mit den neuen VIs werd ich mich hoffentlich noch anfreunden können.
hab aber mal noch ne frage: ich beende ein sub VI mit einem button im haupt VI. am Sub-VI hab ich eingestellt, dass das Sub-VI beim aufruf angezeigt werden soll und nach abarbeitung wieder geschlossen wird. das funktioniert aber nicht. ich kann die messung zwar beenden mir dem stop button, aber das Sub-VI wird trotzdem nicht beendet. es "wartet auf ausführung". woran liegt das?


  sub_vi.vi (Größe: 44,42 KB / Downloads: 296)


  haupt_vi.vi (Größe: 17,57 KB / Downloads: 261)




LG
Claudi