Analogmessung auf einem Kanal im Hintergrund

' schrieb:Beispiel:
Je länger die auslesende Schleife wartet, desto mehr muss sie aus der Queue lesen.
[attachment=53119:QueueGraph_WFM.vi]
[attachment=53118:BD.png]

Wunderbar. vor allem das Auslesen in der for-Schleife - elegant. Ich muss aber trotzdem an der "deutschen" Benennung der Anschlüsse rumnörgeln: das VI Queue leeren hat den von dir genutzten Ausgang so benannt: "Verbliebene Elemente". Total blödsinning in meinen Ausgen, wieso in aller Welt heisst der nicht "Entfernten Elemente"...

' schrieb:Hier zählen Datenfluss und Error-Cluster-Sequenzierung. Von vorne herein also zu denken, ich nehm ein Event, ist falsch, viel zu viele Ebenen zu tief. Zuerst muss du denken: Wie bekomme ich meine Daten per Datenfluss von der Karte auf das Osci-Bild? ... Ein Teil dieses Datenflusses ist das Verwenden von Queues. Queues stellen einen imaginären Datenflus dar.

Ja, macht mir Mühe so zu denken - und ich folge deinem Ansatz; aber die Verwendung von Queues ist ja nicht gerade Datenfluss-orientiert. Versteh mich nicht falsch, Queues sind total prima, und ich werde Sie nutzen - aber man muss meiner Meinung nach bei LabVIEW schon viele Konzepte kennen, und alle kombinieren.

' schrieb:Nur:
Wenn dem jetzt so ist, ist das ja noch schlimmer: Was ist denn, wenn die Eventbearbeitung (aus welche Gründen auch immer, sag ich immer) zu spät kommt: dann läuft der Puffer über. Und dann ist aber das Verfahren, die Task explizit in einer eigenen, parallelen Loop zu bearbeiten und die Daten per Queue zu verschicken, prinzipiell sicherer. Den ganzen Zusatzaufwand mit der Event-Sequenz und dem Bereitstellen des DAQmx-Events kann ich mir also sparen.

Ich sehe das wie du, nur denk ich ja anders: In der Tat gehen bei fehlerhafter Auslegung der Eventbearbeitung, also wenn du nicht SOFORT bei Auftreten des Events (sehe ich als C-Programmierer wie einen Interrupt an) als Callback, oder Datenflussorientiert die Daten ausliest, Daten verloren. Dann machst du aber auch wirklich einen Fehler - man MUSS bei Auftreten eines Events der ja anzeigt die gewünschten Daten sind abzuholen, diese auch sofort holen. Deine LOOP ist da auch nicht besser, denn wenn die die zu langsam machst, übertrieben gesagt, statt 50ms 5 Sekunden gehen auch Daten verloren. Ist also der gleiche Fehler und auch nicht besser. Was ich aber im Kopf habe, ist die Performance bei schwächlichen Rechnern mit z.B. ATOM-CPU - da könnten 50ms LOOPs schon signifikante Anteile an Rechenleistung schlucken. Events hingegen ( vorausgesetzt gut in LV implementiert, was ich aber stark annehme) verbrauchen nur dann CPU-Zeit, wenn Sie auftreten. Aber wenn man die Parameter sinnvoll wählt, dann wirst du schon recht haben, sowohl deine LOOP, als auch meine EVENTS werden sich da nicht viel unterscheiden. Das kommt daher, weil ja der Hardwaretreiber DAQ-MX wunderbar puffert. Würde man das selber machen müssen, dann, ja dann: wären meine Events viel besser.