LabVIEWForum.de

Ich beschäftige mich mit Labview erst seit diesem Jahr, und es sind einige Fragen aufgetaucht, die auch durch Literatur und durch Beiträge hier im Forum nicht beantwortet sehe. Vielleicht kann ja der ein oder andere User hier diese Fragen beantworten.

Da Frag ich mich zuerst, welche Buffer es gibt? Ist dieser Eingangsbuffer der FIFO-Buffer auf der Messkarte? Bei der PCIe6251 hat er eine Größe von etwa 4000 Samples. Was ist der Ausgangpuffer?
Stellen sowohl "Samples per Channel" beim kontinuierlichen Modus als auch das Eingangspuffer-VI diesen Puffer ein?
Puffert das Betriebssystem (hier WindowsXP) auch?
Beim VI "TDMS: Öffnen" gibt es auch einen Punkt "Pufferung deaktivieren". Beschreibt dieser Punkt nur die Pufferung des Schreibvorgangs in die Datei?
Nun zum Lesen:
Die Samplerate gibt an, wie oft ein Signal abgetastet wird. Ist auch die Frequenz der Digitalisierung des analogen Signals?
Werden die Samples dann in den FIFO-Puffer geschrieben und dann von Read gelesen?
Wie schnell ist die funktion "Read"? Hängt das am Betriebssystem? Wenn ja, wie schnell ist WindowsXP, oder wie kann man das heraus bekommen? Arbeitet WindowsXP standardmäsig mit DMA? Wie Langsam ist das Schreiben in eine Datei?

Wie zu erkennen ist, drehen meine Fragen sich hauptsächlich um die Geschwindigkeit der Messung. Ein Puffer sollte möglichst nicht stark genutzt werden. Kann man da überhaupt aussagen drüber machen, wo das System ausgereizt ist?

So ähnliche Fragen hatte ich auch als ich mich mit Datenerfassung zu beschäftigen begann. Es ist auch schwierig, Antworten zu bekommen. Diejenigen, die Bücher über Labview schreiben sind in der Regel reine Software-Fuzzis, die sich wenig oder gar nicht für die hardwaremßige Anbindung von Labview an die reale Außenwelt - Stichwort Messkarte - interessieren. Und das, obwohl Labview eigentlich genau dafür geschrieben wurde.

Allgemeines zur Leistungsfähigkeit: Die Messkarten sind autarke Realtime-Systeme mit eigenem Prozessor oder FPGA. Die Datenerfassung und - ausgabe hat mit LV und Windows gar nichts zu tun - außer daß die Konfiguration von dort aus erfolgt und über Queues der Datenaustausch erfolgt. Die Queues bewirken eine zeitliche Entkopplung. Die Leistungsfähigkeit der Daten-Ein/Ausgabe hängt nur von der Spezifikation der Karte selbst ab - vorausgesetzt natürlich, man macht bei der Konfiguration und bei der Bedienung der Puffer von seiten LV nichts falsch.

Wie ich in einem andere Thread schon sagte, muß man sich um die Puffer seitdem es DAQmx gibt gar nicht mehr kümmern. Ob die Karten internen Puffer allein verwenden, oder zusätzlich noch einen von Labview angelegten Puffer auf dem PC, über die von und zur Karte über DMA zugegriffen wird, daß muß Dich gar nicht interessieren. Das funktioniert einfach perfekt - das ist zumindest meine Erfahrung.
Zur Bezeichnung: Es gilt die Benennung aus PC-Sicht. D.h. der Einganspuffer ist der Puffer für die Datenerfassung (der von der Karte aus gesehen ein Ausgangspuffer ist, was aber nicht gilt).

Zitat:Stellen sowohl "Samples per Channel" beim kontinuierlichen Modus als auch das Eingangspuffer-VI diesen Puffer ein?

Die Frage habe ich hier schon mehrer Male beantworten müssen.
Beim Lesen einer endlichen Zahl von Samples weiß Labview, wie groß der Puffer sein sollte - deshalb gibt es dafür keine extra Einstellung. Anders ist es im Modus "kontinuierlich". Und hier gibt es regelmäßig ein Missverständnis bei der Frage: Was schließe ich am VI "DAQmxTiming" an den Eingang "Samples pro Kanal" an? Die ausführliche Antwort ist: NI überfordert hier den Programmierer, indem es davon ausgeht, daß man sich nicht auf die Eingangsbezeichnungen verläßt, sondern immer in der Hilfe alles liest, bis hin zum Kleingedruckten.
Und da steht: Im kontinuierlichen Modus bedeutet der Eingang etwas ganz anderes, es ist dann die "Größe des Einganspuffers". Da aber wie gesagt LV die Grösse selbst intelligent verwaltet, schließe ich dort nichts an, solange keine Fehlermeldung über zu wenig Puffer kommt. (Was aber noch nie passiert ist)

Arbeitsweise von DAQmxRead:
Ein häufiger Fehlerl ist, daß die Daten einzeln gelesen werden. Damit wird bei hohen Raten das LV-Window-System überfordert. Es sollten also so viele wie möglich Daten auf einmal aus dem Puffer gelesen und zusammen verarbeitet werden.
Das VI wartet, wenn die geforderte Anzahl noch nicht im Puffer ist (Kein zusätzliches Wait in diese Schleife!). Sind die Daten schon im Puffer, dann werden die Daten ohne Wartezeit gelesen.

Arbeitweise von DAQmxWrite:
Man muß im kontinuierlichen Modus zwei Betriebsarten unterscheiden: regenerierend und nicht regenerierend.
Regenerierend: bei periodischer Ausgabe. Die Daten werden nur einmal in den Puffer geschrieben und dann bei der Ausgabe in unendlicher Periode wiederholt.
Nicht regenerierend: Wenn man z.B einen Song über die DAQ-Karte ausgeben will, muß der Puffer ständig mit neuen Daten versorgt werden.
DAQmxWrite schreibt die Daten in den Puffer und wartet nicht, bis die Daten tatsächlich ausgegeben sind. Warten tut es nur dann, wenn der Puffer von einem vorangegangenem Schreibvorgang noch Daten enthält.

Pufferung ist keine Einschränkung der Leistungsfähigkeit (Außer natürlich bei Regelungen). Allerdings habe ich etwas gegen doppelte Pufferung, wie man sie gelegentlich sieht. Das System Karte-PC ist gewissermassen eine Erzeuger-Verbraucher-Struktur in Hardware, mit Kommunikation über Puffer (Der Unterschied ist: Die beiden Systeme arbeiten echt parallel, und nicht quasi-parallel wie bei einer LV-Erzeuger-Verbraucher-Struktur). Das steht aber nirgendwo so geschrieben, und deshalb schieben manche Programmierer, die über die Vorteile der Erzeuger-Verbraucher aufgeklärt worden sind, in Unwissenheit darüber, daß sie schon eine vor sich haben, noch mal eine Erzeuger-Verbraucher-Struktur mit eigenen Queues dazwischen. Die Folge ist dann eine unnötige und leitungsmindernde doppelte Pufferung: einmal hat man die DAQmx-Puffer, und einmal die Pufferung über die in der Erzeuger-Verbraucher-Sruktur benutzten Queue-Funktionen.

Vielen dank für die Antwort!

Interessant finde ich auch folgende Erklärung:
http://itp.tugraz.at/~golubk_a/download/...thods.html
den Absatz "buffered":

Zitat:Buffered

In a buffered acquisition, data is moved from the DAQ device's onboard FIFO memory to a PC buffer using DMA or interrupts before it is transferred to application memory. Buffered acquisitions typically allow for much faster transfer rates than non-buffered acquisitions because data is moved in large blocks, rather than one point at a time.

der Eingangspuffer ist dann wohl dieser FIFO-Buffer auf der Messdatenerfassungskarte?
Labview bzw. der PC holt dann die Daten dort ab (per DMA als Standard) und übergibt sie den Arbeitsspeicher des PC, worauf dann die eigentliche Labview-Software zugreift.
Leider steht da auch nichts, wie groß solche Blöcke sind bzw. wie oft diese Blöcke abgeholt werden.

@Kutter: Nicht alles klein schreiben (vgl. letzter Abschnitt der LVF-Regeln).
Jens

(11.07.2011 19:51 )Kutter schrieb: [ -> ]leider steht da auch nichts, wie groß solche blöcke sind bzw. wie oft diese blöcke abgeholt werden.

Da steht deshalb nichts, weil die Antwort so simpel ist:
Die Blöcke sind so groß, wie am DAQmxRead-Eingang "Anzahl Samples" bytes angeschlossen sind.
Die Blöcke werden so oft abgeholt, so oft die While-Schleife, in der das DAQmxRead in der Regel steht, einen neuen Schleifenumlauf macht.
Alles klar? Merke: DAQmxRead ist, wenn es sich nicht gerade um Einzelmessungen handelt, eine reines Pufferabholungs-VI und hat mit dem Datenlesen, welches der Analog-Digital-Konverter auf der Messkarte macht, nicht das Geringste zu tun. Es mag vielleicht ungeschickt von NI gewesen sein, das VI mit "Read" zu benennen, aber das darf doch kein Grund sein für eine nicht zu reparierende Verständnisblockade.

(11.07.2011 20:36 )jg schrieb: [ -> ]
@Kutter: Nicht alles klein schreiben (vgl. letzter Abschnitt der LVF-Regeln).
Jens

Hallo jg, hab's geändert. Danke für den Hinweis.

@Lucki:
Danke für die Erklärungen. Langsam kommt es an.
DAQmx-Read ließt quasi aus dem Buffer. Und die Daten werden denn da unabhängig von der Schleife reingeschrieben.
Wenn ich "kontinuierlich" lese, werden immer Daten eingelesen und der Buffer hält denn eine bestimmte Anzahl von Samples fest (soviele wie ich bei "Samples to Read" eingestellt habe). Alte Samples werden immer wieder von neuen im Buffer überschrieben.
Wenn ich ich nun den Sample-Modus auf "Endliche Anzahl" stelle, ließt er nur eine Reihe von Samples in den Buffer und endet mit der Aufzeichnung? D.h. ich muss darauf vertrauen, dass die Samples die ich brauche dabei sind.
Da sind ja 4098 Samples nicht gerade viel bei einer längeren Messung. So groß ich nämlich der Buffer der Karte. Und ich dachte immer, bei einem Starttrigger fängt die Karte erst beim Triggersignal an zu messen.
Verstehe ich da irgendwas falsch?

Der Karten-FIFO-Puffer hat eigentlich gar nichts mit den Einstellungen bei den DAQmx-VIs zu tun. Das ist nur der Hardware-Puffer, der dauernd in den Windows-Speicher übertragen wird.

Vielleicht hilft der Screenshot aus der Hilfe zum DAQmx Timing VI weiter:
[attachment=34702]

Also, einen endliche Aufnahme kann auch mehr Samples haben als der Hardware-Puffer der Karte. Bei Einstellung "endlich" ist halt nur vorab bekannt, wie viele Messungen erfolgen sollen. Die kann man übrigens schrittweise per DAQmx-Read abholen, auch wenn die Gesamtmessung noch nicht vorhanden ist.

Gruß, Jens

P.S.: Danke fürs Editieren.