Analogmessung auf einem Kanal im Hintergrund

Der "wahre" Grund für die eventgesteuerte Datenerfassung scheint mir also dieser zu sein

' schrieb:Erstens habe ich in C als DLL bereits daq-mx mit DAQmxRegisterEveryNSamplesEvent erfolgreich benutzt, ...

Was man halt schon kennt ... nimmt man dann auch.


@IchSelbst: Warum ist es ein Vorteil den Puffer sampleratenunabhängigen zu leeren/lesen? Ich benutz 'ne ganz normale Schleife und die Iterationszeit ergibt sich automatisch aus Sampling Rate * Anzahl der Samples.

Anzeige

' schrieb:Warum ist es ein Vorteil den Puffer sampleratenunabhängigen zu leeren/lesen

Bei 1MHz Samplerate und 100 Samples wäre die Schleifendauer 100µs. Das ist aber schon sehr, sehr, sehr knapp. Willst du eine akzeptable Schleifendauer haben, muss du immer die Sampleanzahl an die Samplerate anpassen. Vorteil dieser Methode: Die Datenpakete sind immer gleich lang.

Benutzt du aber den Algorithmus "alle 50ms alles, was da ist, lesen", ist die Schleifendauer unabhängig. Außerdem musst du hier nicht warten, bis der Puffer die erforderliche Anzahl von Daten enthält. Für meine Weiterverarbeitung ist es unerheblich, ob die Datenpakete 10, 100 oder 1000 Datensätze enthalten.

Erst mal vielen Dank an alle, momentan lerne ich viel.

dimitri84 wie machst du das, dass bei deinen Zitaten so schön steht von wems ist ?

Zitat:Bei 1MHz Samplerate und 100 Samples wäre die Schleifendauer 100µs. Das ist aber schon sehr, sehr, sehr knapp. Willst du eine akzeptable Schleifendauer haben, muss du immer die Sampleanzahl an die Samplerate anpassen. Vorteil dieser Methode: Die Datenpakete sind immer gleich lang.

Benutzt du aber den Algorithmus "alle 50ms alles, was da ist, lesen", ist die Schleifendauer unabhängig. Außerdem musst du hier nicht warten, bis der Puffer die erforderliche Anzahl von Daten enthält. Für meine Weiterverarbeitung ist es unerheblich, ob die Datenpakete 10, 100 oder 1000 Datensätze enthalten.

Ich habe immer längere Zeiten als 100uS im Kopf wenn ich was mit Windows mache, ich halte daher deine 50ms, besser noch 100ms für gut. Natürlich lese ich die Samples nicht einzeln, sondern Blockweise. Ich wollte aber je nach verwendeter Hardware (PCI, USB oder RS232...) im Benutzerinterface die Blockgröße einstellbar machen, also Samplerate und Blockgröße (=Eventfrequenz) sinnvoll einstellen (100ms für mich absolut ausreichend, selbst sekündlich ist ok). Gerade so ein Graph braucht lang, 50ms können da je nach Inhalt schon zu kurz sein, es muss daher vorher sinnvoll reduziert (z.B.: Datenmittelung etc) werden.

Zitat:Das weis man (also ich) nicht. Der Event könnte eine richtige Message sein - einschließlich Daten. D.h. zum Zeitpunkt des Auftretens wird eine Message gemacht mit den Daten eines Samples. Wäre dem so (und ich befürchte so) gehen keine Daten verloren.

Glaub ich nicht, dass mit dem generieren des Event schon Daten aus dem DAQ-MX Device ausgelesen werden. Event ist etwas, das vom Betriebssystem unterstützt wird, und von daher performant und CPU-schonend. Es ist aber meines wissens nach nur so eine Art Flag, ohne Daten. Daher müssen die Daten ja mit einer Art DAQ-MX-read funktion als Reaktion auf das event gelesen werden.

Zitat:Zum Koppeln gibt es Queues.

Erwischt. Daran habe ich mich bisher nicht getraut. Ich verwende ja Queues beim Erzeuger-Verbraucher-Modell, wie in meinem geposteten Beispiel-code zu sehen, besteht die Queue bei mir aus einem ENUM (Nachrichtenart) und 4 Strings (quasi um Argumente als text kodiert übertragen zu können). Aber ich habe keine Ahnung wie ich es anstellen könnte, eine Queue zu bauen, die aus variabel großen Messdatenblöcken besteht. Gibts da ein Beispiel?

Den "Danken" Button hast du doch schon gefunden. Der daneben ist, wie der name schon sagt, zum "Zitieren". Einfach drücken (er wird rot) und dann antworten und der Text erscheint im Antwortfenster.

Queues musst du nicht selbst bauen. Die gibts fertig. Einfach mal die SyncPalette anschauen.

' schrieb:Queues musst du nicht selbst bauen. Die gibts fertig. Einfach mal die SyncPalette anschauen.

Und so eine Queue kann als Datentyp Signalverlauf, und diese sogar unterschiedlich Groß, mal mehr und mal weniger Samples ? Das ist ja toll...

Beispiel:

Je länger die auslesende Schleife wartet, desto mehr muss sie aus der Queue lesen.


  QueueGraph_WFM.vi (Größe: 28,77 KB / Downloads: 175)


   

Gruß SeBa

Anzeige

' schrieb:Event ist etwas, das vom Betriebssystem unterstützt wird, und von daher performant und CPU-schonend.

Oh! Zwei Sachen:
Du gehörst jetzt als LabVIEW-Programmierer einer höheren Kaste an. In dieser Kaste zählen Denkweisen, die man sich als C++- respektiver OOP-Programmierer angeeignet hat, nicht mehr viel. 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.
Wenn du sagt, Event ist etwas vom Betriebssystem Unterstütztes, dann unterschlägst du die LV-Runtime. Es ist noch lange nicht gesagt, dass ein Event vom Betriebssystem kommt. LV respektive seine RT bohren sich dermaßen tief ins Betriebssystem ein, da glaube ich gerne, dass so mancher Event am Betriebssystem vorbei alleine von der LV-RT gemanagert wird.

Zitat:Daher müssen die Daten ja mit einer Art DAQ-MX-read funktion als Reaktion auf das event gelesen werden.

Hab ich kein Problem mit. Es gibt also solche und solche Events. 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.


Noch geschwind ein weiteres Wort zu "sampelratenunabhängig":
"Samplerate" ist eine Eigenschaft einer bestimmten Ebene innerhalb einer hierarchischen Struktur. Und zwar der Ebene "Daten Samplen und in Puffer ablegen". Diese Ebene befindet sind (weit?) unterhalb der Ebene, die für das Auslesen des Puffers (DAQmx-Read) zuständig ist. Auch in LV gilt das Prinzip der Kapselung, zu deutsch: Was interessieren mich Parameter, die einer anderen Ebene gehören (von Initialisieren diverser Ebenen mal abgesehen)? Ich (eine beliebige Ebene) brauch die nicht! So gesehen, sollte die Ebene "DAQmx-Read" also sampelratenunabhängig sein. Eine solche Denkweise resultiert aus der Überlegung, dass meine Probleme, die ich mit Entwicklung und Debugging habe, mit der Anzahl der Parameter steigen (respektive sinken).

Vielleicht sehe ich das falsch aber ...

... Ebenen parameterunabhängiger zu gestalten bedeuetet doch auch immer einen gewissen Mehraufwand respektive ( ) eine komplexere Struktur. Hier z.B.: Normale Schleife gegen Timed-Loop mit Erzeuger Verbraucher Struktur. Wenn man also mit den Nachteilen der parameterabhängigereren Struktur leben kann, oder sogar gut Leben kann, oder sogar Vorteile darin sieht, ist das Prinzip der Kapselung zu hinterfragen respektive nicht pauschal als vorteilhaft anzusehen.

' schrieb:... Ebenen parameterunabhängiger zu gestalten bedeuetet doch auch immer einen gewissen Mehraufwand respektive ( ) eine komplexere Struktur.

Mehraufwand ja, komplexere Struktur auf keinen Fall.
Eine Kapselung führt immer zu einer einfacheren Struktur. Der Mehraufwand resultiert daher, weil man nicht direkt auf einen Parameter außerhalb der eigenen Ebene (Klasse, Modul, etc) zugreifen soll. Was gänge, wäre der Parameter als z.B Globale Variable typisiert. Man soll also in der anderen Ebene (Klasse, Modul etc.) ein Property schaffen, um dann auf dem Umweg über den Property-Aufruf an den Parameter zu kommen. (Mit Property hat die Klasse die Möglichkeit zu Zugriff zu verweigern, was nicht geht, wenn der Parameter in einer GV liegt). Ein "Property" in einer "FGV" ist der Enum-Eingang in Verbindung mit einem (leider) Variant Ein-/Ausgang.

Zitat:Hier z.B.: Normale Schleife gegen Timed-Loop mit Erzeuger Verbraucher Struktur. Wenn man also mit den Nachteilen der parameterabhängigereren Struktur leben kann, oder sogar gut Leben kann, oder sogar Vorteile darin sieht, ist das Prinzip der Kapselung zu hinterfragen respektive nicht pauschal als vorteilhaft anzusehen.

Hinterfragt werden kann das Prinzip der Kapselung nicht. Und es ist auch per se immer besser.

Das Problem ist halt immer die Verhältnismäßigkeit. Wenn, wollte ich der Kapselung gerecht werden, wenn ich also extremen Aufwand treiben muss, nur um ein Feature für 5Cent zu realisieren, wird keiner (und ich schon gar nicht) Einwände haben. Irgendwann kann ich nämlich absehen, dass die Nicht-Einhaltung der Kapselung in diesem einen Falle eigentlich gar nichts ausmacht. Was aber nichts daran ändert, dass es nach Lehrbuch falsch ist.

Und wenn ich hier einen (virtuellen) Vortrag halte, dann muss ich mich immer zuerst an die Lehrbuchmeinung halten. Zumindest dann, wenn einer ganz allgemeine Fragen hat. Danach kommen erst die durch die Praxis gegeben Einschränkungen.

' 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.