Kommunikation zw. Haupt- und Sub-VI

Hallo,
ich hab schon ein bisschen im Forum herumgeschaut, bin aber nicht wirklich auf die richtige Lösung gestoßen.
Ziel:
Das Haupt-VI soll nur zur Erfassung von Benutzereingaben dienen. Es gibt (im Moment nur 1) ein Sub-VI, dass die Messaufgabe übernimmt. Es soll kontinuierlich seine Daten rausschreiben und ins Haupt-VI (dort geschieht die Anzeige) übertragen. So lange bis die Abbruchbedingung aus dem Haupt-VI kommt.
Problem:
Das Sub-VI als normales VI funktioniert, jedoch die Kommunikation zw. Haupt- und Sub-VI nicht. Anschlüsse sind vorhanden!

Danke

(Beide in Version 8.5)
Haupt-VI:

  Hauptprogramm.vi (Größe: 22,83 KB / Downloads: 437)


Sub-VI:

  AnalogwertEinlesen2AI_DAQmx_SubVI_.vi (Größe: 35,09 KB / Downloads: 339)

Schau dir mal die beiden VIs an. Das Datenverbraucher-Vi ist das Hauptprogramm, das Datenerzeuger-VI entspricht Deinem DAQmx-VI. Die erzeugten Daten werden über einen Melder (oder besser Queue) an das Hauptprogramm gegeben. Das Sub-Vi synchronisiert das Haupt-VI, da der Melde-Empfänger immer werten muß, bis neue Daten anliegen.
Wenn das Hauptrogramm gestoppt wird. wird der Melder "zerstörend" freigegeben. Das erzeugt natürlich im Melde-Sender im Sub-Vi eine Fehlermeldung. Diese beendet das Sub-VI.
Man kann es natürlich auch anders machen, aber Du wirst sowieso nicht umhin können, ein Queue zur Datenübertragung zum Hauptprogramm zu verwenden. Dann ist es so das Einfachste.
(Beim Datentransport über eine globale Variable hättest Du, abgesehen davon das es langsamer ist, das Problem der Synchronisation)

Und hier den Melder in Dein DAQ-VI eingefügt

Danke für die schnelle Antwort! Hab aber erst in ein paar Tagen Zeit mir das genauer anzusehen. Meld mich dann wieder.
EDIT: Hab's nimmer erwarten können. Also, wenn ich das richtig verstehe was dein Programm macht: Das DAQmx-VI läuft immer und übergibt dem Main-VI immer die Daten über die Queue.

Dazu hätte ich dann noch einige Fragen:

Ich würde die Messdatenerfassung gerne erst mit Kommando starten, da wäre es doch besser das Sub-VI erst später zu starten oder?
Und ich würde die Erfassung gerne mit einer Taste aus dem Hauptprogramm abbrechen können, dieses soll aber weiterlaufen. Verwendet man hierzu eine globale Variable?
Was ist der Unterschied zwischen Melder und Queue? Unter Synchronisierung findet man nämlich beides.

Dann gibt's da noch Unklarheiten beim Sub-VI:

Was bezweckst du mit dem Schalter Testmode?
Ist deine Lösung mit der Aktualisierung der Datenerfassung (Sample Rate/Rate Aktualisierung) besser als immer nur die Daten herauszugeben, die beim letzten Aufruf zur Verfügung standen (und das mit "Verfüfbare Samples pro Kanal" abzufragen)?

Danke für deine Hilfe!
lg. PHilipp

Entschuldige, manchmal brauch ich ein bisschen länger. Hab es geschafft mit deinem modifizierten Programm meines zusammenzubauen.
Ich hätte aber trotzdem noch ein paar Fragen (die von oben übriggeblieben sind):

Was ist der Unterschied zwischen Melder und Queue? Unter Synchronisierung findet man nämlich beides.
Was bezweckst du mit dem Schalter Testmode?
Ist deine Lösung mit der Aktualisierung der Datenerfassung (Sample Rate/Rate Aktualisierung) besser als immer nur die Daten herauszugeben, die beim letzten Aufruf zur Verfügung standen (und das mit "Verfüfbare Samples pro Kanal" abzufragen)?

Lg, Philipp

PS: Mein modifiziertes Programm:
(LV 8.5)

  Hauptprogramm.vi (Größe: 27,05 KB / Downloads: 360)


  DAQmx_Sub.vi (Größe: 40,95 KB / Downloads: 349)

Was ist ein Notifier?
Was ist eine Queue

Der Button "Testmode" ermoeglicht das Testen des DAQmx SubVIs -> reine Funktionsueberpruefung.
False: Werte werden in den Notifier geschrieben
True: True Case wird abgearbeitet und solange der User NICHT den Schalter von TRUE auf FALSE zurueck stellt, wird KEIN fiktiver Fehler erzeugt, der die Schleife abbricht.

Durch die Anzahl der zu lesenden Samples beim DAQmx Read erzwingt man ein implizites Timing. Die Read Funktion pollt die Anzahl der empfangenen Samples nicht. Ein weiterer Vorteil ist die Vermeidung von dynamischer Speicherallokierung.

Anzeige

' schrieb:Was ist ein Notifier?
Was ist eine Queue

Durch die Anzahl der zu lesenden Samples beim DAQmx Read erzwingt man ein implizites Timing. Die Read Funktion pollt die Anzahl der empfangenen Samples nicht. Ein weiterer Vorteil ist die Vermeidung von dynamischer Speicherallokierung.

Danke. Den Unterschied zwischen Notifier und Queue hab ich so ziemlich verstanden: Notifier unterbricht das Hauptprogramm wenn Daten kommen, Queue schreibt die Daten kontinuierlich in einen Puffer, dieser wird dann vom Hauptprogramm ausgelesen. Das mit Notofier funktioniert mit polling eh recht ähnlich wie eine Queue.

Aber was versteht man unter implizitem Timing? Durch Anzahl Samples sagst du dem Read doch nur wieviele Samples es sich abholen soll. Oder meinst du damit, dass es warten muss, bis soundsoviele Daten zur Verfügung stehen?
Was meinst du mit dynamischer Speicherallokierung?

lg, PHILIPP

' schrieb:Danke. Den Unterschied zwischen Notifier und Queue hab ich so ziemlich verstanden: Notifier unterbricht das Hauptprogramm wenn Daten kommen, Queue schreibt die Daten kontinuierlich in einen Puffer, dieser wird dann vom Hauptprogramm ausgelesen. Das mit Notofier funktioniert mit polling eh recht ähnlich wie eine Queue.

Aber was versteht man unter implizitem Timing? Durch Anzahl Samples sagst du dem Read doch nur wieviele Samples es sich abholen soll. Oder meinst du damit, dass es warten muss, bis soundsoviele Daten zur Verfügung stehen?
Was meinst du mit dynamischer Speicherallokierung?

lg, PHILIPP

Freedive hat selbstverständlich recht: Den "Testmode" in dem VI hatte ich vorgesehen, damit man die Datenerfassung autark ohne das Hauptprogramm testen kann.

"Implizites Timing" ist kein offizieller Begriff, Freedive meint damit, daß die While-Schlife, in der sich das QAQmx Read befindet, entsprechend dem Datenaufkommen getimed und mit den Daten synchronisiert wird, ohne das sich dazu in der Schleife ein Timer befindet.

Die Datenerfassung wird hardwaremäsig vom internen Timer auf der Messkarte getaktet und die Samples kommen in der Regel erst einmal in einen Buffer. Das DAQmx Read hat mit dem Timing der Datenerfassung überhaupt nichts zu tun, da es nur die Daten aus dem Puffer liest. Es hat aber sehr wohl zu tun mit dem Timing bei der Datenverarbeitung und deren Synchronisation mit der Datenerassung, und zwar funktioniert es so:

In der Regel wird eine Anzahl von Daten festgelegt, die gelesen werden sollen, z.B. N=10. Das VI Read wartet dann geduldig mit der dem Lesen, bis 10 Samples im Buffer sind (D.h es blockiert so lange, so wie es die Wait-Funktion auch tut) ). Damit ergibt sich das richtige Timing mit der Datenerfassung und die Synchronisation. Pech ist es natürlich, wenn die Datenverarbeitung in der Schleife zu lange dauert. Bei 100 Daten im Buffer werden auch nur 10 Werte herausgelesen, und wenn die Datenerzeugung schneller ist als die Verarbeitung, dann füllt sich der Buffer immer mehr, bis es zum Überlauf kommt.

Man kann DAQmx read auch anweisen, alle Daten im Buffer auszulesen. Aber selbst dann ist hier kein Polling (= laufendes Nachfragen, ob schon etwas im Buffer ist) erforderlich. Denn wenn der Buffer ganz leer ist, dann wartet das VI, bis wenigstens 1 Sample im Buffer ist, so daß auch hier die Datenverarbeitung in der Schleife nie mit leeren Daten dasteht.

PS: Wer in die Schleife mit DAQmx Read noch eine Wait-Funktion einbaut, outet sich als jemand, der dieses Prinzip noch nicht verstanden hat. Man sieht das hier bei Anfängern leider immer wieder.

Danke vielmals. Kenn mich jetzt aus.

' schrieb:Danke vielmals. Kenn mich jetzt aus.

Ich noch nicht ganz, deshalb mal eine Frage dazu von mir

Ich habe ein Problem mit dem Notifier. Also wie hier beschrieben läuft das ganze
quasi als Erzeuger/Verbraucher.

Der Erzeuger fordert einen Melder an des Typs "Signalverlauf". Dieser Verlauf wird dann
mit "Meldung senden" losgeschickt. Das Signal einlesen geschieht jede Sekunde, somit
wird auch jede Sekunde die neue Meldung losgeschickt. Soweit so gut. Der Verbraucher
fordert diesen Melder nun an und mit "auf Meldung warten" verarbeitet er den Melderinhalt.
Klappt auch alles soweit. Nun ist es aber ja so, dass während der Melder wartet der restliche
Programmteil lahmgelegt ist. Befinden sich jetzt im Verbraucher zum Beispiel Eigenschaftsknoten
eines Graphen, die mit Schiebern oder Textfelder verändert werden können, werden diese auch
nur jede Sekunde aktualisiert. Das ganze sieht dann ziemlich ruckartig und hakelig aus.

Wie kann ich es lösen, dass quasi nur die Anzeige mit dem Melder arbeitet aber die Graphenmanipulation
nicht darauf warten muss. Muss ich dabei vielleicht mit zwei parallelen While-Schleifen arbeiten?
Funktionieren tut das ganze ja, aber sieht net schön aus wenn man es bedienen will...

edit: Ich meine sowas wie im Anhang. Der Eigenschaftsknoten sollte unabhängig von
der Wartezeit des Melders sofort den neuen Wert bekommen.

edit2: Ich habs auch mit Queue versucht, aber der Erzeuger packt dann immer das Signal dort hinein
und der Verbraucher kommt quasi nicht nach. Wenn das Signal sich nach längerer Zeit ändert,
dauert es lange bis dies beim Verbraucher angezeigt wird, da die Queue rappelvoll ist und erst alles
nacheinander angezeigt wird (Ich glaub den Satz versteht man nicht...)

edit3: Ich muss noch dazu sagen, dass bei einem Erzeuger ca. 10 Verbraucher da sind, so dass der
1. Verbraucher zum Beispiel beim Queue-Einsatz diese nicht leeren darf, da die andern den Inhalt auch noch brauchen.
So, mehr fällt mir (vorerst) nicht dazu ein.