Analogmessung auf einem Kanal im Hintergrund

Und was ist, wenn das besagte subVI via VI-Server gestartet wurde? Dann sind doch beide Event-Strukturen scharf, oder? Ist das auch "erlaubt"?

Jetzt wo ich drüber nachdenke wird mir bewusst, dass ich das einmal paar mal schon so gemacht habe.

Wieso sind dann beide scharf?

Gruß Markus

' schrieb:Und was ist, wenn das besagte subVI via VI-Server gestartet wurde? Dann sind doch beide Event-Strukturen scharf, oder? Ist das auch "erlaubt"?

Jetzt wo ich drüber nachdenke wird mir bewusst, dass ich das einmal paar mal schon so gemacht habe.

Hi,
ich verstehs noch immer nicht.

Zitat:Nur wenn Du innerhalb eines VIs (auf die Hierarchieebene bezogen) 2 Eventstrukturen hast kriegst Du u.U. Probleme. Im VI darüber oder darunter kannst Du ruhig wieder eine Eventstruktur verwenden.

Zitat:Nein, die Empfehlung lautet wirklich pro VI max. 1 Event-Structure. In einem SubVI darf ruhig wieder eine Event-Structure sein, wenn sinnvoll. Beispiel: z.B. ein Dialogfenster.

Wenn ich in meinem Haupt-VI eine Event-Struktur habe, und als Extrembeispiel 3 while Schleifen irgendow ausserhalb allem anderen in denen dann 3 verschiedene SUB-VIs mit jeweils einer eigenen Eventstruktur parallel laufen, geht das dann ? Ich sehe nicht ein worin der Unterschied liegt, statt der SUB-VIs direkt den Code in den whiles zu platzieren.

Die Idee: eine Event-Struktur für die GUI, und drei als DAQ-MX event für 3 verschiedene DAQ-MX tasks für die Hintergrundmessdatenerfassung.

Wie schon gesagt. Wenn Du ein SubVI mit Event-Struktur aufrufst, ist diese Event-Struktur aktiv. Das Hauptprogramm wartet bis das SubVI abgearbeitet wurde. Ist der Code (mit Eventstruktur) nicht in einem SubVI sondern direkt in Deiner Schleife des HauptVIs, dann sind u.U. beide Eventstrukturen dauerhaft aktiv. Pro While-Schleife eine Event-Struktur macht "in der Regel" wie in dem oberen Link schon beschrieben nichts aus, wird aber nicht empfohlen.

Gruß Markus

' schrieb:Wieso sind dann beide scharf?

Na weil doch beide aktiv sind und ich beide gleichzeitig verwenden kann. Ich kann doch im Haupt-VI immer noch die Benutzeroberfläche bedienen (eventgesteuert), denn der Code wartet nicht bis das subVI (ebenfalls mit Eventstruktur) abgearbeitet wurde.

Mir sind aber dabei keine Probleme ausgefallen.

Hätte ich nur gestern gleich was geschrieben.

LV ist ohne weiteres in der Lage, innerhalb eines VIs mehrere Eventstrukturen zu verarbeiten. Auch innerhalb einer While-Schleife. Das Problem ist nicht LV - sondern der Anwender. Y-P hat ein Beispiel verlinkt, das das beschreibt.

Event-Strukturen haben besondere Eigenschaften, z.B. FP sperren. Gesetzt der Fall, ein Event in der ersten Eventstruktur sperrt das FP und ein Event in der zweiten Eventstruktur sperrt es nicht. Was passiert nun, wenn bei gleichzeitig (das geht!) bearbeitet werden sollen? Wird das FP geperrt oder nicht? Aus dem verlinkten Beispiel könnt ihr schlussfolgern, dass zwei Event-Sequenzen letztendlich zu deinem Deadlock führen können.

In einfachen Programmen werden zwei paralle Event-Sequenzen funktionieren. Wird das Programm aber komplexer und ist "einfach strukturiert", so wird der Programmierer in Unkenntnis des Sachverhaltes da Sachen hineinprogarmmieren, die in einfachen Fällen zu Inkonsistenzen führen werden, aber auch zu RaceConditions - und letztendlich auch zu Deadlocks. Derartige Fehler aber sind weder wiederholbar, noch nachvollziehbar, geschweige denn vorhersehbar. Und da der Programmierer nichts faslches findet, ist am Schluss wieder LabVIEW an allem Schuld.

Die Vorgabe, keine zwei Event-Sequenzen zu verwenden, kommt also eher daher, weil NI vorbeugen will, dass Programmierer "unfähigen Code" erzeugen.

In unterschiedlichen VIs - auch in verschachtelten - können ohne weiteres Event-Strukturen parallel laufen. Wie gesagt: LV kann das ab. Bei mir läuft das MainVI, das ein SubVI per VI-Server (in einem SubPanel) aufruft, immer parallel zum SubVI weiter (d.h. ich hab zwei FP gleichzeitig zur Bedienung freigegeben). Sind die Event-Sequenzen in unterschiedlichen VIs ist die Wahrscheinlichkeit der gegenseitigen Beeinflussung lediglich(!) um Potenzen geringer. Daher verbietet man ein solches Vorgehen nicht derart vehement wie in einem SubVI.

wernerIBN kann ohne weiteres zwei Event-Sequenzen verwenden. Er muss sich nur im Klaren sein, dass das zu schwerwiegenden Problem führen kann - weil er nämlich einen inkonsistenten Algorithmus programmieren könnte. Die Frage ist nur, ob zwei Event-Seqeunzen überhaupt notwendig sind. Ich sage, in 99.99% aller Fälle ist eine einzige Event-Sequenz ausreichend. Wegen Geschwindigkeit und/oder Verlust von Events muss sich keiner Gedanken machen. Das packt LV alles.

Anzeige

Zitat:wernerIBN kann ohne weiteres zwei Event-Sequenzen verwenden. Er muss sich nur im Klaren sein, dass das zu schwerwiegenden Problem führen kann - weil er nämlich einen inkonsistenten Algorithmus programmieren könnte. Die Frage ist nur, ob zwei Event-Seqeunzen überhaupt notwendig sind. Ich sage, in 99.99% aller Fälle ist eine einzige Event-Sequenz ausreichend. Wegen Geschwindigkeit und/oder Verlust von Events muss sich keiner Gedanken machen. Das packt LV alles.

Tolles Posting.

Genau der Punkt "Wegen Geschwindigkeit und/oder Verlust von Events muss sich keiner Gedanken machen. " beschäftigte mich.

Ich habe eine Eventstruktur für die GUI im Erzeuger-Verbraucher-Pattern, und die zweite Eventstruktur AUSSCHLIESSLICH für die DAQ-MX-Events.
Mit der zweiten Eventstruktur mache ich NIX, aber auch GARNIX anderes, als die ganze Zeit im Hintergrund DAQ-MX events auszulesen.

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

Findest du, "IchSelbst", dieses Vorgehen für mich gut oder schlecht, ich bitte um deine geschätzte Meinung.

Nun noch zur Performance:

Zitat:Wegen Geschwindigkeit und/oder Verlust von Events muss sich keiner Gedanken machen. Das packt LV alles.

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.

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.

Richtig oder falsch ?

Worin liegt eigentlich die Indikation die Datenerfassung eventgesteuert zu gestalten? Hast du dir das Beispiel zufällig rausgesucht oder bewusst ausgewählt?

Was willst du überhaupt erfassen? Wieviel? Wie schnell?

Zitat:Worin liegt eigentlich die Indikation die Datenerfassung eventgesteuert zu gestalten? Hast du dir das Beispiel zufällig rausgesucht oder bewusst ausgewählt?

Bewusst ausgesucht.

Erstens habe ich in C als DLL bereits daq-mx mit DAQmxRegisterEveryNSamplesEvent erfolgreich benutzt, und zweitens möchte ich permanent im Hintergrund messen und in einem Graph wie ein Scope anzeigen. Beispielsweise so, als ob man statt virtueller Geräte eben ein echtes Oszilloskop auf dem Tisch stehen hat. Der Anwender verfährt mit einer Motorsteuerung die Probe, und nimmt dabei Spannungen auf, die ich LIve anzeigen muss, damit er weiss, was in seiner Apparatur passiert.

Das Ganze mit events zu lösen schien mir praktisch und CPU-schonend. Die Messung läuft permanent, immer. Vom Start des Programms bis zu Ende. Abspeichern muss man nur ab und zu, das lös ich mit deinem Beispiel , danke nochmal.

Alternativ bleibt ja nur pollen, oder eine Schleife, das mit dem Benutzerinterface zu kombinieren schien mir schwierig, daher die events.

Zitat:Was willst du überhaupt erfassen? Wieviel? Wie schnell?

Eine Spannung, mit etwa 10 kHz. Ich nehm dazu ein USB-6211.

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