LabVIEWForum.de

Hallo Miteinander,
ich erstelle gerade ein VI zum Steuern eines Versuchsaufbaus für Sensoren. Ich habe auch ein VI zusammengebastelt, das bisher alle meine Anforderungen irgendwie (!) erfüllt, wobei auch noch nicht alle Geräte da sind, so dass ich einige Teile noch nicht einarbeiten konnte. Mir geht es jetzt um Hinweise, tipps und RAtschläge darüber, was ich prinzipiell an dem Programm - besser gesagt an dem Programmierstil - verbessern kann. Es geht also (noch) nicht um bessere Lösungen eines individuellen Problems, sondern um bessere Lösungen allgmein.
Um solche Hinweise zu ermöglichen, werde ich kurz beschreiben, welche Anforderungen ich erfüllen will (und von denen ich meine, dass ich sie erfüllt habe). Motiviert durch diverse Forumeinträge habe ich mir auch selbst schon überlegt was ich evtl verbessern könnte oder sollte. Diese Überlegungen werde ich ebenfalls Preis geben.
Ich habe das VI so wie es jetzt vorliegt innerhalb von 4 Wochen erstellt, wobei das mein erster Kontakt mit LV überhaupt ist. Das WIssen habe ich aus Tutorials, den LV Beispielen und der Hilfe sowie aus diesem Forum erlangt.

Anforderungen:
- 4 AI: Sensorspannung, Sensorstrom, zwei TEmperatursensoren Pt1000
- Steuerung eines Lineartisches, d.h. Signalausgabe und Eingang der Position x
- Darstellung der Sensorspannung/Tischposition graphisch:U/t,U/x,x/t
- Anzeige der Temperaturwerte der beiden Pt1000 Sensoren numerisch und auf Knopfdruck graphischer Verlauf "langsamer" als U-x Graphen
- 1 AO: Spannungsversorgung des Sensors
- Start des Speicherns auf Knopfdruck "Messung"
- Einstellung der Messparameter, ohne die keine Speicherung stattfinden kann
- Auswahl eines beliebigen Speicherortes auf Knopfdruck; wenn keiner ausgewählt wird, wird Vorgabepfad verwendet. Wenn "Messung" gedrückt wird, soll neue Datei erzeugt werden, falls aktuelle schon existiert.

Diese Anforderungen habe ich erfüllt, wobei die Aufzeichnungen bisher alle Spannungen sind, da noch keine Sensoren angeschlossen sind. Der REst funktioniert soweit (habe PCI-6221 Karte in Verbindung mit SCC-68, LV 8.5).
Meine Fragen allgemeiner Natur sind die folgenden:
1. Was hat es mit den Timing einstellungen in einer While SChleife genau auf sich? Warum packe ich da sone Uhr rein und was genau nehme ich wann (Warten auf Vielfaches, bzw Warten) ?
Ich habe herausgefunden, dass es die CPU entlastet, aber ich will genau wissen, welches Timing SChleifen haben. Werden die beim Messen son schnell ausgeführt wie die Abtastrate es vorgibt, oder wie sieht das aus?
2. Sollte ich mehr SubVIs benutzen? Wenn ja, wo macht es Sinn und warum?
Ich hatte mir z.b. überlegt, dass ich das Auftrennen meines Arrays aus Singanlverläufen in ein SubVI stecken könnte und dort auch das Verzögern der Temperaturdarstellung mache. Anschließend im HauptVI nur noch die Grapohen bzw Diagramme einfügen.
3. Sollte ich mehrere Schleifen verwenden?
4. Wie ist das mit den Eigenschaftsknoten, die ich verwende? Sollte ich die zu Gunsten von CAse-Strukturen rausschmeißen?
Es ist kein Problem die Eigenschaftsknoten rauszuschmeißen und Case-Struktur(en) zu verwenden. Nur weiß ich nicht genau was mehr Speicher bzw. Ressourcen frisst.

Ok, das ist jetzt alles sehr umfangreich. Ich weise nochmals daruaf hin, dass ich mir keinesfalls erwarte, dass ihr mein Programm schreibt bzw. Mir sagt wie ich dies und das in meinem konkreten FAll löse. Vielmehr geht es mir darum prinzipielle Dinge über LV anhand meiner Probleme zu lernen und dann mein Programm so gut es geht zu erstellen. Ich will es selbst hinkriegen, nur brauche ich Tipps, in welcher Art es am besten wäre es hinzukriegen.

Ich hoffe, ihr versteht um was es mir geht.

vielen herzlichen Dank schonmal für jeglichen Tipp und Hinweis.
Viele GRüße
Wolfgang

Hallo, Wolfgang,

' schrieb:Hallo Miteinander,
ich erstelle gerade ein VI zum Steuern eines Versuchsaufbaus für Sensoren. Ich habe auch ein VI zusammengebastelt, das bisher alle meine Anforderungen irgendwie (!) erfüllt, wobei auch noch nicht alle Geräte da sind, so dass ich einige Teile noch nicht einarbeiten konnte. Mir geht es jetzt um Hinweise, tipps und RAtschläge darüber, was ich prinzipiell an dem Programm - besser gesagt an dem Programmierstil - verbessern kann. Es geht also (noch) nicht um bessere Lösungen eines individuellen Problems, sondern um bessere Lösungen allgmein.
Um solche Hinweise zu ermöglichen, werde ich kurz beschreiben, welche Anforderungen ich erfüllen will (und von denen ich meine, dass ich sie erfüllt habe). Motiviert durch diverse Forumeinträge habe ich mir auch selbst schon überlegt was ich evtl verbessern könnte oder sollte. Diese Überlegungen werde ich ebenfalls Preis geben.
Ich habe das VI so wie es jetzt vorliegt innerhalb von 4 Wochen erstellt, wobei das mein erster Kontakt mit LV überhaupt ist. Das WIssen habe ich aus Tutorials, den LV Beispielen und der Hilfe sowie aus diesem Forum erlangt.

für 4 Wochen LV ist das doch schon mal gar nicht schlecht.

Erster Kritikpunkt: Mach die Labels bei den Terminals im BD sichtbar, das erhöht die Lesbarkeit des Codes. Das Label eines Controls ist ja sozusagen der Variablenname, und ein sinnvoller und "selbsterklärender" Variablennamen ist immer gut. Wenn dieses Label dann nicht als Beschriftung im FP taugt, dann kann man ja immer noch im FP auf die "Caption" eines Controls zurückgreifen.

Dann: Zur vollständigen Analyse fehlt die Info, wie du dein Task "Messung" genau konfiguriert hast. Am besten hier mal LV-Code erstellen und noch mal hochladen.

Zitat:Anforderungen:
- 4 AI: Sensorspannung, Sensorstrom, zwei TEmperatursensoren Pt1000
- Steuerung eines Lineartisches, d.h. Signalausgabe und Eingang der Position x
- Darstellung der Sensorspannung/Tischposition graphisch:U/t,U/x,x/t
- Anzeige der Temperaturwerte der beiden Pt1000 Sensoren numerisch und auf Knopfdruck graphischer Verlauf "langsamer" als U-x Graphen
- 1 AO: Spannungsversorgung des Sensors
- Start des Speicherns auf Knopfdruck "Messung"
- Einstellung der Messparameter, ohne die keine Speicherung stattfinden kann
- Auswahl eines beliebigen Speicherortes auf Knopfdruck; wenn keiner ausgewählt wird, wird Vorgabepfad verwendet. Wenn "Messung" gedrückt wird, soll neue Datei erzeugt werden, falls aktuelle schon existiert.

Diese Anforderungen habe ich erfüllt, wobei die Aufzeichnungen bisher alle Spannungen sind, da noch keine Sensoren angeschlossen sind. Der REst funktioniert soweit (habe PCI-6221 Karte in Verbindung mit SCC-68, LV 8.5).
Meine Fragen allgemeiner Natur sind die folgenden:
1. Was hat es mit den Timing einstellungen in einer While SChleife genau auf sich? Warum packe ich da sone Uhr rein und was genau nehme ich wann (Warten auf Vielfaches, bzw Warten) ?
Ich habe herausgefunden, dass es die CPU entlastet, aber ich will genau wissen, welches Timing SChleifen haben. Werden die beim Messen son schnell ausgeführt wie die Abtastrate es vorgibt, oder wie sieht das aus?

Eine Schleife läuft in LV immer so schnell, wie es der Code innerhalb der Schleife zulässt. Wenn dort also nichts zur "Zeitverzögerung" drin ist, wird schnell 100% CPU Belegung erzeugt. Eingaben sind dann kaum noch möglich.
Deswegen packt man gerne solche Wait-VI's in Schleifen ein. Das sind übrigens dann Software-Taktungen, man sollte sich da nicht allzu genau auf das Timing verlassen.

Das hat nichts mit der Abtastrate von Messungen zu tun.

Zum Thema kontinuierliche Datenerfassung mit Hardware-Taktung habe ich übrigens kürzlich erst hier so einige Beispiele hochgeladen:
http://www.LabVIEWforum.de/index.php?showtopic=8099&hl=. Schau dir das mal an.

Zitat:2. Sollte ich mehr SubVIs benutzen? Wenn ja, wo macht es Sinn und warum?
Ich hatte mir z.b. überlegt, dass ich das Auftrennen meines Arrays aus Singanlverläufen in ein SubVI stecken könnte und dort auch das Verzögern der Temperaturdarstellung mache. Anschließend im HauptVI nur noch die Grapohen bzw Diagramme einfügen.

Beim momentanen Stand nicht unbedingt. Was jetzt aber nicht heißen soll, das man keine SubVI'S verwenden soll, im Gegenteil! SubVI's sind immer gut, wenn man eine Aufgabe mehrfach an verschieden Stellen eine Programmes zu erledigen hat, und sie verkleinern den Platz im BD eines VIs (BD <= Bilschirmgrösse).

Zum Punkt Aufsplitten der Messwaveform, das hast du etwas umständlich gemacht. Einfacher so:

[attachment=10580]

Zitat:3. Sollte ich mehrere Schleifen verwenden?

Kommt darauf an. Was man z.B. machen könnte und was wahrscheinlich auch keine schlechte Idee wäre, ist eine parallele Schleife, in der du per Event-Struktur auf das Betätigen deiner verschieden Buttons reagierst. Hier könntest du die Eigenschaftsknoten von Punkt 4 deiner Frage dann reinstecken, dann werden diese Sachen nicht bei jedem Schleifendurchlauf gesetzt. Auch das mit der Auswahl des Speicherfiles läuft aus meiner Sicht noch nicht so, wie du es willst. In jedem Schleifendurchlauf wird ja immer wieder der Datenpfad auf deinen Default-Pfad gesetzt (Timeout-Case der Event-Struktur). Und die Case-Struktur um den File-Dialog kannst du dir sparen, denn der File-Dialog wird wegen der Event-Structure nur dann aufgerufen, wenn du den Pfad-wählen Button drückst. Bei Latch-Verhalten eine Buttons sollte man auch eher beim Verhalten "Latch when released" bleiben, sonst hat man als User in der Regel keine Rückmeldung, dass man den Button betätigt hat.

Ob dein AO-Task mit einem unterschiedlichem Timing zum AI-Task laufen soll, das musst du selber wissen.

Zitat:4. Wie ist das mit den Eigenschaftsknoten, die ich verwende? Sollte ich die zu Gunsten von CAse-Strukturen rausschmeißen?
Es ist kein Problem die Eigenschaftsknoten rauszuschmeißen und Case-Struktur(en) zu verwenden. Nur weiß ich nicht genau was mehr Speicher bzw. Ressourcen frisst.

Jaja, das Thema Property-Nodes. Ja, sie sind "langsam" und haben einen gewissen "Overhead". Andererseits, wenn es nicht um extrem zeitkritische Abläufe geht, und der PC nicht gerade eine "uralte lahme Kiste" ist, dann ist meine Meinung, was solls. Bin selber häufiger und intensiver Nutzer von PropertyNodes, um das FP nach meinem Geschmack zu gestalten.

Zitat:Ok, das ist jetzt alles sehr umfangreich. Ich weise nochmals daruaf hin, dass ich mir keinesfalls erwarte, dass ihr mein Programm schreibt bzw. Mir sagt wie ich dies und das in meinem konkreten FAll löse. Vielmehr geht es mir darum prinzipielle Dinge über LV anhand meiner Probleme zu lernen und dann mein Programm so gut es geht zu erstellen. Ich will es selbst hinkriegen, nur brauche ich Tipps, in welcher Art es am besten wäre es hinzukriegen.

Ich hoffe, ihr versteht um was es mir geht.

vielen herzlichen Dank schonmal für jeglichen Tipp und Hinweis.
Viele GRüße
Wolfgang

MfG, Jens

P.S.: Und in Zukuft bitte LV-Version bei hochgeladenen VIs angeben.

Hallo Jens,
danke erstmal für deine ausführliche Antwort. Da sind schon mal einige Sachen für mich verständlicher.

' schrieb:Erster Kritikpunkt: Mach die Labels bei den Terminals im BD sichtbar, das erhöht die Lesbarkeit des Codes. Das Label eines Controls ist ja sozusagen der Variablenname, und ein sinnvoller und "selbsterklärender" Variablennamen ist immer gut. Wenn dieses Label dann nicht als Beschriftung im FP taugt, dann kann man ja immer noch im FP auf die "Caption" eines Controls zurückgreifen.

Hatte ich anfangs und hab auch überlegt das zu lassen, hab die Labels dann aber zugunsten des Platzes rausgesschmissen. Für Nachfolger ist es aber sicher besser, da hast du recht. Ist geändert.

Zitat:Dann: Zur vollständigen Analyse fehlt die Info, wie du dein Task "Messung" genau konfiguriert hast. Am besten hier mal LV-Code erstellen und noch mal hochladen.

Ich habe im MAX zunbächst vier virtuelle Kanäle erstellt und diese dann in einen Task gepackt. Hab jetzt im VI mal den Code generiert (siehe unten), wodurch allerdings die Vorgabe von einem Bildschirm fürs BD nicht mehr erfüllt ist.

Zitat:Eine Schleife läuft in LV immer so schnell, wie es der Code innerhalb der Schleife zulässt. Wenn dort also nichts zur "Zeitverzögerung" drin ist, wird schnell 100% CPU Belegung erzeugt. Eingaben sind dann kaum noch möglich.
Deswegen packt man gerne solche Wait-VI's in Schleifen ein. Das sind übrigens dann Software-Taktungen, man sollte sich da nicht allzu genau auf das Timing verlassen.

Ich hab jetzt ein bisschen nachgedacht und mit dem Timing rumgespielt und es glaub ich mittlerweile besser verstanden. Auch dann den Zusammenhang mit der Abtastrate und den aus diesen beiden Größen letzlich resultierenden Datenmengen

Zitat:Zum Thema kontinuierliche Datenerfassung mit Hardware-Taktung habe ich übrigens kürzlich erst hier so einige Beispiele hochgeladen:
http://www.LabVIEWforum.de/index.php?showtopic=8099&hl=. Schau dir das mal an.

Die Beispiele die du an anderer Stelle hochgeladen hast, habe ich mir schon angeschaut (ich weiß gar nicht wieviele Stunden ich schon in diesem Forum gelesen habe...), nur sehe ich nicht genau den Vorteil in meinem Fall. Außerdem habe ich nicht ganz verstanden wie du den Graph-Cluster aufbaust. Vielleicht könntest du das kurz erklären. Ansonten denke ich, dass meine Schleife nicht lange genug läuft um den Buffer zu füllen, zumindest ergibt das die Rechnung und ich hatte auch schon lange keine solche Fehlermeldung mehr. Ganz am Anfang hab ich das nicht geblickt mit dem buffer, aber mittlerweile geht es hoffentlich einigermaßen.

Zitat:Zum Punkt Aufsplitten der Messwaveform, das hast du etwas umständlich gemacht. Einfacher so:

Du hast beim Aufteilen des Arrays nur eine 0 als Index verwendet. Ich habe doch theoretisch 4 Signalverläufe, die ich aufsplitten muss, d.h. jeder müsste einen einzelnen Index haben oder? Diesen Teil habe ich im VI auch noch überarbeitet. Die GRaphen bzw. Diagramm der Temperatur laufen jetzt langsamer. Dazu habe ich "dezimieren" benutzt. Das müsste doch im Prinzip dann so sein, wie wenn ich weniger oft messen würde, weil nur ein Teil der Messwerte benutzt werden oder versteh ich das falsch? Ich habe es in meinem VI mal in dem von dir dargestellten Sinne geändert und die Indizes so angepasst wie ich denke.
Dazu direkt wieder eine Verständnis Frage:
Wie werden solche Mess-Arrays aufgebaut? Als Zeilen- oder Spaltenmatrix? Also wenn ich einen Kanal habe mit einem Signalverlauf, kommt dann eine Zeile raus oder eine Spalte?

Zitat:Kommt darauf an. Was man z.B. machen könnte und was wahrscheinlich auch keine schlechte Idee wäre, ist eine parallele Schleife, in der du per Event-Struktur auf das Betätigen deiner verschieden Buttons reagierst. Hier könntest du die Eigenschaftsknoten von Punkt 4 deiner Frage dann reinstecken, dann werden diese Sachen nicht bei jedem Schleifendurchlauf gesetzt.

Ja, an sowas in der ARt hatte ich auch schon nachgedacht, weil ich es nicht so doll finde, wenn die immer aufgerufen werden.

Zitat:Auch das mit der Auswahl des Speicherfiles läuft aus meiner Sicht noch nicht so, wie du es willst. In jedem Schleifendurchlauf wird ja immer wieder der Datenpfad auf deinen Default-Pfad gesetzt (Timeout-Case der Event-Struktur). Und die Case-Struktur um den File-Dialog kannst du dir sparen, denn der File-Dialog wird wegen der Event-Structure nur dann aufgerufen, wenn du den Pfad-wählen Button drückst.

Das habe ich mittlerweile selbst schon behoben. Es läuft jetzt so wie ich mir das vorstelle, d.h. bei jedem neuen Aufnehmen von Daten wird ein neues File generiert. vorher wars bei jedem SChleifen Durchlauf, da hast du recht.
die Case Struktur in der Event Struktur habe ich mit einem bestimmten Grund gemacht bzw. mangels genauem Verständnis der Ereignis-Strukturen. Und zwar hatte ich so etwas in der Hilfe gelesen, dass der Button, auf den sich die WErtänderung bezieht immer verbunden sein sollte. Zumindest habe ich das so verstanden. Daher die Case Struktur, um wuasi den Status von "Speichern" abzufragen. Kann natürlich sein, dass ich das einfach komplett falsch verstanden habe. Ansonsten ist die Case-Struktur natürlich quatsch. Daher also die Frage:
Müssen die Schalter o.ä. auf die sich die Events beziehen, an irgendwas angeschlossen sein oder kann ich die einfach ohne irgendwas anderes reinpacken? Das würde einiges vereinfachen.

Zitat:Ob dein AO-Task mit einem unterschiedlichem Timing zum AI-Task laufen soll, das musst du selber wissen.

Das macht nichts. ich brauch nur eine konstante Spannung während der Messung und das müsste gegeben sein oder?

In meinem jetztigen VI sind einige Buttons enthalten die noch keine Funktion haben(unten im BD), bitte die nicht so beachten. Damit will ich die Tischsteuerung dann basteln, sobald der da ist. Hab das nur reingepackt, damit ich das FP soweit fertig gestaltet habe.

Ich hab die LV Version in meinem Profil geschrieben und oben in meinem Thread nochmal. Aber hast recht, der Einfachheit halber ist es direkt beim VI wesentlich sinnvoller. WErd mich dran halten.


Viele GRüße
Wolfgang

LV Version 8.5
[attachment=10588]

Hallo,

gleich mal ein absolutes NO-NO: Nicht mehr als 1 Event-Structure innerhalb einer While-Loop anlegen, das führt auf Dauer zu Ärger im Programm.

Dann zur Konfiguration AI und Größe BD: Das bietet sich jetzt doch für ein SubVI an!

Dann zum VI "Array Index": Wenn an den Eingängen nichts angeschlossen ist, dann ist der erste Index immer automatisch "0", und wenn man dieses VI aufzieht, dann wird nach unten immer automatisch um 1 erhöht. Deshalb hatte ich nichts weiter angeschlossen, sogar die 0 war bei mir überflüssig, aber das lasse ich meist der Übersichtlichkeit halber drin.

Und zum Abschluß nochmal zur kontinuierlichen (zeitlich nicht begrenzten) Datenerfassung:
Der Eingang "Anzahl der Samples" am Timing-VI legt beim Kontinuerlich-Modus die Größe des FIFO-Puffers fest. In diesem Puffer (der meines Wissens nach schon im RAM von Windows liegt und nichts mehr mit dem Hardware-Puffer auf einer DAQ-Karte zu tun hat) schiebt dann der DAQmx-Treiber also immer die Messwerte auf First-In-First-Out-Basis.
Man kann sich die Daten aber ruhig schon aus diesem Puffer holen, bevor er "voll" ist, also jederzeit. Hierzu bietet sich z.B. der Anschluss "-1" am Read-VI an, oder wie auch schon häufiger vorgeschlagen, man schaut per PropertyNode nach, wieviele Samples gerade im Puffer liegen, und liest dann diese Menge aus. Ebenfalls toll ist natürlich auch das Event-gesteuerte Einlesen, wenn es die Version des DAQmx-Treibers halt anbietet (weiss jemand auswendig, aber welcher DAQmx-Version das geht?). Somit wird man beim Übertragen der Daten in sein Programm eigentlich vollkommen unabhängig von irgendwelchen Timings, mit denen man While-Schleifen laufen lässt, denn auf diese Timings kann man sich bei Windows sowieso nicht verlassen. Und dann sollte bei richtiger Wahl der Parameter auch kein Überschreiben des Datenpuffers geschehen.

MfG, Jens

Hallo,
ich hab mittlerweile noch ein bisschen am VI rumgebastelt.

' schrieb:gleich mal ein absolutes NO-NO: Nicht mehr als 1 Event-Structure innerhalb einer While-Loop anlegen, das führt auf Dauer zu Ärger im Programm.

Hab alles in eine packen können.

Zitat:Dann zur Konfiguration AI und Größe BD: Das bietet sich jetzt doch für ein SubVI an!

Ich hab wieder einfach den MAX TAsk reingepackt, da sieht man zwar den expliziten code nicht, aber ist dafür schön handlich und bei bedarf kann man sich den code ja generieren lassen.
Hat sich aber nix wesentlich geändert, ich hab nur versucht die Fehler zu korrigieren, daher poste ich das VI nicht. Jetzt erstelle ich ein VI mit dem ich einfache Auswertungen meiner daten durchführen kann, wobei noch ein paar fragen aufgetaucht sind.
ZUm wohl ewig währenden Thema property nodes:
Ich verwende sie im neuen vi viel, aber nicht in schleifen, also eigentlich nur um mein Frontpanel beim aufruf des VIs richtig zu konfigurieren. Vor allem in einem SubVI verwende ich property nodes um auch anfangswerte zu setzen. Ist das in ordnung, wenn sie nur einmal aufgerufen werden, oder sollte ich das dann auch vermeiden und evtl lieber mit was anderem (variablen oder referenzen - wie auch immer das dann genau auszusehen hat) arbeiten?

Viele GRüße und vielen Dank für jegliche Hilfe
Wolfgang

Ich hätte nochmal eine Frage und zwar zum Thema State Machine. Ich habe mir überlegt, dass es doch evtl sinnvoll wäre mein VI von oben in eine State machnie zu verlegen, so dass die Messung und Darstellung kontinuierlich abläuft, das Speichern der Daten aber nur bei Aktivierung eines SChlaters abläuft. Ich habe mir verschiedene Beiträge zum Thema State Machine durchgelesen, habe auch selbst schon stm mit Case und Event Strukturen erstellt, aber in diesem FAll, müsste ich doch wohl auf Queues oder Notifier zurückgreifen, wenn ich das richtig verstanden habe.
Wann genau nehme ich Queues und wann Notifier?
Es wäre sehr hilfreich wenn mir jemand die Funktionsweise dieser beiden Dinge genau erklären könnte oder ein einfaches Beispiel einer StM erstellen könnte. Gar nicht mal auf mein VI bezogen, sondern einfach in den jeweiligen State als TExt reinschreiben was dort abgearbeitet werden sollte.

Ach ja, ich habe übrigens nicht das Toolkit für die Einführung in die StM installiert...

Herzlichen Dank,
Wolfgang

' schrieb:Ach ja, ich habe übrigens nicht das Toolkit für die Einführung in die StM installiert...

Das State Machine Toolkit brauchst du nicht...das ist im Prinzip nur ein Assistent, der dir die Grundstruktur erzeugt...das kriegste auch manuell ganz leicht hin!

' schrieb:Das State Machine Toolkit brauchst du nicht...das ist im Prinzip nur ein Assistent, der dir die Grundstruktur erzeugt...das kriegste auch manuell ganz leicht hin!

Ich hatte das nur erwähnt um zu verdeutlichen, dass ich mir nicht gut eine grundstruktur selbst ansehen kann und ich also mehr oder weniger auf hilfe von hier angewiesen bin. Prinzipiell ist mir eigentlich klar wie so eine StM aufgebaut wird nur fehlt mir das genaue Verständnis von Queues bzw Notifiern um die wirklich sinnvoll einzusetzen.

Öffne z.B. mal ein neues VI über den Menüpunkt File->New..., da öffnet sich dann ein Assistent, in dem einiges als Template (z.B. State-Machine, Consumer-Producer, etc.) hinterlegt ist.

Oder schau dir mal das Terminal-VI von Eugen an.

MfG, Jens

Danke für die hinweise, daraus kann ich mir schonmal das Grundprinzip abschauen.

' schrieb:Öffne z.B. mal ein neues VI über den Menüpunkt File->New..., da öffnet sich dann ein Assistent, in dem einiges als Template (z.B. State-Machine, Consumer-Producer, etc.) hinterlegt ist.

Oder schau dir mal das Terminal-VI von Eugen an.

Hab ich jetzt beides gemacht, wobei das genau mein Problemn trifft
Eg verwendet in seinem Terminal-Beispiel Queues und in der Vorlage zu Master/Slave Schleifen werden Notifier verwendet. Also was genau ist der Unterschied zwischen denen und wann nehme ich was?
In der Hilfe steht bei beidem, dass es zum Datenaustausch zwischen SChleifen bzw zwischen VIs dient.