DAQmx Fehler -200279, von Puffern und schritthaltenden Erfassungen

@IchSelbst: Genau, das aus Erfahrung optimale unter Windows.

--

Ich sehe das so: Die Frage und das Bsp von stoa sind von extrem akademischer Natur, da hier die automatische Buffergröße auf DAQmx-Treiber-Ebene ausgehebelt wird. Wenn ich das noch richtig im Kopf habe, und mein Link zur Bufferbeschreibung bestärkt mich in dieser Erinnerung, dann haben wir in Realität mehrere Puffer bei NI-Karten.

Meist gibt es einen kleinen Puffer direkt auf der Karte, an den man aber nicht unbedingt programmatisch dran kommt. Da erfolgt bei Bedarf die erste Zwischenspeicherung.
Dann gibt es die Puffergröße auf Treiber-Ebene, die im NI-Link beschrieben wird. Aus diesem Puffer müssen die Daten immer wieder nach Windows (quasi ins RAM) geschoben werden, wo sie bei Bedarf auch noch mal (quasi im DAQmx-Read) gepuffert werden, bevor sie dann per DAQmx-Read abgeholt werden in LabVIEW.

Wird jetzt, wie in diesem Bsp, die automatische Puffergröße auf Treiber-Ebene so radiakal unterschritten, dann führt das eben zu Fehlermeldungen.

Vielleicht irre ich mich auch bei der Beschreibung, und die Puffergröße wird auf der Karte angelegt, aber am Ende kommt es auf dasselbe hinaus. Durch das Begrenzen dieses Puffers schafft es DAQmx je nach Karte nicht mehr, die Daten schnell genug ins "RAM" von DAQmx zu schieben.

Gruß, Jens

(24.02.2021 17:36 )jg schrieb:  Ich sehe das so: Die Frage und das Bsp von stoa sind von extrem akademischer Natur,

Dem kann ich nur zustimmen. und auch alles, was in Richtung "lass das den Treiber machen" geht...

Dennoch ist das Thema nicht uninteressant.

@stoa: Ich habe dein Beispiel vom ersten Beitrag genommen, eine X beliebige simulierte Datenerfassungskarte "installiert", das VI von einem globalen Channel umgestellt (den wollte ich nicht im MAX einrichten). Das aktuellere VI von dir sieht dann so aus wie im Anhang.

Lustigerweise funktioniert das mit dem simulierten Gerät problemlos, wenn ich die Anzahl der Abfragen auf 5 oder niedriger einstelle. Dann bleibt die Anzahl der verfügbaren Samples unter 500. Nun sind insgesamt 2000ms Zeit und es müssten theoretisch 19 Abfragen möglich sein. Lustigerweise verhält sich zumindest das simulierte Gerät sehr eigenartig. Ohne diese Abfragen oder bis 5 Abfragen funktioniert es ohne Fehlermeldung (bei der letzten Abfrage sind rund 400 Samples im Puffer). Wenn ich jedoch 7 mal abfrage, dann bekomme ich eine Fehlermeldung wegen eines Pufferüberlaufs. Bei 7 Abfragen hätte ich etwas in der Art wie 100 Samples oder ähnliches erwartet.

Ich vermute ja fast, dass er erst durch die Abfrage von Available "Samples per Channel" merkt, dass ja eigentlich der Puffer übergelaufen ist und ohne diese Abfrage merkt er das gar nicht. Das kann an dem simulierten DAQ Gerät liegen. Wenn das eine echte Hardware genauso macht, dann fällt mir im Moment dazu nichts mehr ein.

Da ich gerade nix besseres greifbar habe, würde mich schon interessieren, was bei dir (stoa) heraus kommt. Das angehängte VI fragt mit den Defaulteinstellungen nur 5 mal ab - funktioniert das so? und was passiert, wenn du die Abfrage 7 mal machst?

Nachtrag: 02.03.2021 (ich hatte den Anhang vergessen)

(24.02.2021 21:01 )Martin.Henz schrieb:  @stoa: Ich habe dein Beispiel vom ersten Beitrag genommen, eine X beliebige simulierte Datenerfassungskarte "installiert", das VI von einem globalen Channel umgestellt (den wollte ich nicht im MAX einrichten). Das aktuellere VI von dir sieht dann so aus wie im Anhang.

Selbst das hat einen Einfluss auf das Bsp, s. mein P.S.

Zitat: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.

Da hat wohl NI was reinprogrammiert in den DAQmx-Treiber...

Gruß, Jens

Hallo zusammen,

entschuldigt, die letzten Tage war es etwas stressig. Da konnte ich mich nicht beteiligen.

Zitat:Meist gibt es einen kleinen Puffer direkt auf der Karte, an den man aber nicht unbedingt programmatisch dran kommt. Da erfolgt bei Bedarf die erste Zwischenspeicherung.
Dann gibt es die Puffergröße auf Treiber-Ebene, die im NI-Link beschrieben wird. Aus diesem Puffer müssen die Daten immer wieder nach Windows (quasi ins RAM) geschoben werden, wo sie bei Bedarf auch noch mal (quasi im DAQmx-Read) gepuffert werden, bevor sie dann per DAQmx-Read abgeholt werden in LabVIEW.

Wenn es sich so verhält wie du schreibst, dann erklärt es zumindest, warum es möglich ist, aus einem Puffer, den man auf 50000 Werte beschränkt, 100000 Werte entnehmen kann. Nämlich dann, wenn dazwischen ein weiterer Puffer ist, der sich einfach zwei Mal 50000 nimmt. Das bedeutet aber wiederum, dass DAQmx-Read den zu kleinen Puffer mehrfach leert. Und wenn ich den Puffer auf die Größer einer halben Menge zu erwartender Samples reduziere, verkraftet DAQmx-Read keine Verzögerungen mehr > 1/2 * Zykluszeit, denn nach 1/2 * Zykluszeit ist 1/2 * Ganzer_Puffer übergelaufen. So sieht's wohl aus.

Zitat:Das aktuellere VI von dir sieht dann so aus wie im Anhang.

@Martin.Henz: Deinen Anhang kann ich nicht sehen. Kannst du das nochmal kontrollieren? Oder übersehe ich den gerade irgendwie?

mit Gruß
stoa

(01.03.2021 12:56 )stoa schrieb:  @Martin.Henz: Deinen Anhang kann ich nicht sehen. Kannst du das nochmal kontrollieren? Oder übersehe ich den gerade irgendwie?

ok, ich habe es oben eingefügt.
(als simuliertes Device hatte ich eine PCI-6110 als "Dev3" verwendet)

(02.03.2021 12:31 )Martin.Henz schrieb:  

(01.03.2021 12:56 )stoa schrieb:  @Martin.Henz: Deinen Anhang kann ich nicht sehen. Kannst du das nochmal kontrollieren? Oder übersehe ich den gerade irgendwie?

ok, ich habe es oben eingefügt.
(als simuliertes Device hatte ich eine PCI-6110 als "Dev3" verwendet)

Würdest du mir noch einen LV2019-Export machen?

(03.03.2021 12:05 )stoa schrieb:  Würdest du mir noch einen LV2019-Export machen?

was hab ich jetzt angestellt

Ich hatte es für LV2017 gespeichert, aber dann das falsche VI hochgeladen.
Tschuldigung - Ich habe es jetzt ausgetauscht.

Hallo Martin,

bei mir gibt es sofort einen -200796. Habe das Programm zu nichts überreden können. Bildschirmfoto anbei...

Dann belassen wir es dabei, dass es mit einem simulierten Geräten schwieriger ist, den Treiber abzuklopfen... und dass da doch einiges mehr im Treiber passiert... und mann nicht alles im Leben haben kann?

vielen Dank, alles Gute, bleibt gesund und bis bald!
stoa