' schrieb:Das ganze ist meiner Meinung nach aufgeräumter im Blockdiagramm, als diese DAQ-MX-Events von der zweiten Event-Struktur in die eh schon umfangreiche Eventstruktur des Erzeuger-Verbraucher events "reinzuverkabeln".
Von diesem Standpunkt aus stimme ich dir voll und ganz zu.
Zitat:Findest du, "IchSelbst", dieses Vorgehen für mich gut oder schlecht, ich bitte um deine geschätzte Meinung.
In wie weit das Verwenden von Events für DAQmx-Read einen Performance- oder strukturellen Vorteil bringt weiß ich nicht. Möglicherweise ist dem so. Ich hab das aber noch nie so gemacht - und auch nicht ausprobiert: Weil es nämlich keine Veranlassung dafür gibt. (Das war jetzt die Umschreibung von schlecht.)
Ich mach das immer so:
Mach eine parallele, unabhängige 50ms-Loop. In der ließt du ein einziges Mal den kompletten DAQmx-Puffer leer. Diesen Satz Sample-Daten verschickst du per Queue - wohin immer du willst. Das ganze Management mit dem Puffer macht ja bereits der DAQmx. Für dich ist es - egal was du machst - immer ausreichend, in einem festen, sampleratenunabhängigen Rasten den Puffer leer zu lesen.
Zitat:Würde ich die DAQ-MX events mit in eine einzige Eventstruktur nehmen, und der würde ein anderes event länger dauern als die zeit zwischen zwei DAQ-MX events gehen doch DAQ-MX-events, also Messdaten, verloren.
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.
Zitat:Eine zweite, eigene Eventstruktur für die DAQ-MX-events hingegen läuft doch parallel, und somit nicht Gefahr Messdaten durch andere langsame Events zu verlieren.
Das ist eine Milchmädchenrechnung! Daten gehen nur dann nicht verloren, wenn diese eine Event-Sequenz schneller ist als das "Event-Raster". Du willst 10kHz? Das sind 100µs, da hab ich aber allergrößte Zweifel, dass die Event-Sequenz schneller ist.
Wenn der DAQmx-Event lediglich sagt, dass jetzt neue Daten da sind, die jetzt mit einem expliziten DAQmx-Read gelesen werden müssen(!), dann ist die Event-Methode prinzipiell schlechter als die "50ms-Loop-Methoden". Zumal sie auch noch Sample-Rate-unabhängig ist.
' schrieb:und zweitens möchte ich permanent im Hintergrund messen und in einem Graph wie ein Scope anzeigen.
Kein Problem mit der von mir beschriebenen Vorgehensweise.
Zitat:Das Ganze mit events zu lösen schien mir praktisch und CPU-schonend.
Nunja.
Zitat:Die Messung läuft permanent, immer. Vom Start des Programms bis zu Ende. Abspeichern muss man nur ab und zu,
Genau so läuft das bei mir auch - nur halt mit dieser parallelen Loop.
Zitat:Alternativ bleibt ja nur pollen, oder eine Schleife, das mit dem Benutzerinterface zu kombinieren schien mir schwierig, daher die events.
Zum Koppeln gibt es Queues.
/
Analogmessung auf einem Kanal im Hintergrund
