INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Puffern und Lesen



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

10.07.2011, 10:07 (Dieser Beitrag wurde zuletzt bearbeitet: 10.07.2011 12:42 von Lucki.)
Beitrag #2

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Puffern und Lesen
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Nachrichten in diesem Thema
Puffern und Lesen - Kutter - 09.07.2011, 10:06
RE: Puffern und Lesen - Lucki - 10.07.2011 10:07
RE: Puffern und Lesen - Kutter - 11.07.2011, 19:51
RE: Puffern und Lesen - Lucki - 12.07.2011, 06:59
RE: Puffern und Lesen - jg - 11.07.2011, 20:36
RE: Puffern und Lesen - Kutter - 17.07.2011, 14:19
RE: Puffern und Lesen - jg - 17.07.2011, 17:59

Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  DAQmx Fehler -200279, von Puffern und schritthaltenden Erfassungen stoa 17 9.516 04.03.2021 14:02
Letzter Beitrag: stoa

Gehe zu: