Verhalten von Ereignisstrukturen

Hallo,

ich räume gerade mein Programm auf. Bisher habe ich mich vor Ereignisstrukturen gedrückt, alles irgendwie umgangen. Nun habe ich Schieberegister und Drähte, die über 10 Bildschirme breit miteinander verbunden sind und nur in jedem 50000 Schleifendurchlauf mal benutzt werden. Daher möchte ich diese jetzt durch lokale Variabeln und Ereignisstrukturen ersetzten.

Wenn ich das richtig verstanden habe, dann wird jeweils nur ein Element aus den vielen Ereignissen verarbeitet. Also wenn Ich Button 1 - 5 in einer Ereignisstruktur unterbringe, welche in einer Schleife sitzt, würde jeweils nur ein Klick verarbeitet werden, der Erste.

Was passiert mit den anderen Klicks? Wird beim nächsten Schleifendurchlauf dann das zweite Eregniss abgearbeitet? Ergibt sich sozusagen ein Puffer?

Noch irgendwelche Hinweise/Tutorials, was ich bei Ereignissen beachten muss?

Ich überlege, ob ich die Verzögerung der While-Schleife, welche um die Ereignisstruktur ist, nicht entfernen kann und dies über die Timeout-Zeit der Ereignisstruktur steuere. Der einzige Unterschied wäre doch, dass bei einem Ereignis die While Schleife schnell ein zweites Mal ausgeführt wird. Löst das vllt schon das Problem mit dem Puffer?

Grüße,

Takuro

Du solltest generell versuchen mit so wenigen lokalen Variablen wie möglich auszukommen. Um was für ein Programm handelt es sich? Ist eine Event-Structure wirklich sinnvoll? Hast auch einmal in Erwägung gezogen, dein auf mehrere Bildschimgrößen verteiltes Programm in einer State-Machine unter zu bringen?

Gruß,

Soean

Hi,
Die Beschreibung von 10 Bildschirmseiten lässt sich bei mir auch die Fußnägel hochrollen, aber um Deine Frage zu beantworten:

Es gibt eine Ereignis-Queue, wenn ich also für fünf Buttons Ereignisse definiere und davon drei drücke, werden die auch nacheinander abgearbeitet. Auf diese Ereignis-Queue kann man meines Wissens nach und auch nach Auskunft eines NI-Trainers NICHT zugreifen, sprich, wenn ich gedrückt habe, läuft das ganze auch entsprechend durch. Abhilfe kann man mit der Kombination "Frontpanel-Aktivitäten während Event-Ausführung deaktivieren" (Haken im Event-Konfigurationsmenü recht weit unten, meine ich) und entsprechenden Aktivierungen und Deaktivierungen der Knöpfe im Event-Case realisieren.

Zu den Tipps und Erfahrungen nur folgendes:
- Den Anschluss des Bedienelements möglcihst in den Event-Case reinpacken, wo das auch bearbeitet wird - das macht das ganze ein bisschen zuverlässiger, wenn man mit Click-Events arbeitet. Parallele, nicht deterministische Programmabarbeitung in LV und so...
- Ich persönlich bin großer Fan von State-Machines mit einem Event-Case, der die entsprechende Programfunktion steuert und halt für jede Funktion einen eigenen State hat. Könnte Deine 10 Bildschirmseiten auflösen und dann kann man sich auch tatsächlich das Wait in der While-Schleife sparen. Falls die einzelnen Programmteile an sich recht simpel sind (also nur von einer Konfiguration abhängen) und man diese ggf. auch mehrfach nutzen möchte, sind Queued State Machines eine coole Sache, weil man dann einfach mehrere Dinge nacheinander programmieren kann und m.E. die Fehlerbehandlung einfacher zu machen ist, weil man an jeder STelle an jede Stelle des Programms springen kann, ohne sich die vorherigen Zustände merken zu müssen. Geht in der State Machine nur kompliziert...

Grüße und viel Spaß,

ch

Die fortschrittlichste Architektur überhaupt - von ch schon angedeuted - ist die Event-driven queued State-machine, siehe hier. Wenn Du alles noch mal überarbeitest, würde ich an Deiner Stelle so etwas machen.
Wenn man sich mit dem Backen kleinerer Brötchen begnügt, gibt es erst mal drei Möglichkeiten, wie man die Event-Struktur platziert:
1) in einer Schleife parallel zur Haupschleife (Timout = -1, unendlich)
2) In der Hauptschleife (wenn Wait in der Hauptschleife erforderlich, dann als Timout der Eventstruktur).
2a) Das ganze Hauptprogramm im Timeout-case der Eventstruktur ausführen
2b) Das Hauptprogramm außerhalb außerhalb der Event-Struktur ausführen, Timeout-Case bleibt leer.

Jedes hat sein Vor-und Nachteile bzw. Eigenheiten. Meine eigenen Preferenzen entsprechen der genannten Reihenfolge.

Es handelt sich um die Steurung eines Messstandes. Im Groben das Ansprechen und Abfragen von 2 Analysatoren, mehrere Sensoren in einem Reaktor, Steuerung von 3 Volumenströmen und Beleuchtung. Dazu halt Datensicherung und entsprechende Automatisierung der Anlage. Sprich anmachen, diverse Messparametersätze vorgeben und dann in 2 Wochen wiederkommen.

Das ganze läuft in Schleife, in der noch ein Case Fall sitzt, welcher nur aktiv wird, wenn die Messung gestartet wird. Die Parametereingabe usw läuft bisher parallel zum Case Fall in der Schleife. (Ich hoffe es ist so klar, sonst mach ich nochmal ne Skizze)

Ich steure im Case Fall nun über eine weitere Schleife die MEssung: Kontrolle der Volumenströme, Verarbeitung der MEssdaten usw.

Das ganze besteht halt schon aus Recht vielen Drähten. Und da ich immer fleißig den Aufräumenbutton nutze, der mich aber nicht mag, hab ich nun auch einige Leerräume dazwischen. Deswegen 10 Seiten. Deswegen nutze ich auch lokale Variabeln. Wenn ich ganz am Anfang der Messung etwas in die Header Dateischreibe und diesen Wert aber zum Rechnen für jeden Messwertsatz brauche, ist das sonst ein gewirr von Drähten. Hatte ich am Anfang, extrem unfreundlich zu lesen.

Und nun versuche ich halt weiter das zu vereinfachen und Übersichtlicher zu gestalten. Ich "kenne" zwar die Begriffe Staemaschine, Ereignisstruktur usw, hab aber null Ahnung davon. Dieses Prijekt ist leider auch mein erstes, sonst bin ich als Chemiker eher wenig damit bewandert...

Ich werde morgen mal den Link durcharbeiten. Falls noch jemand Erleuchtungen hat, gerne her damit.

Danke schonmal,

Takuro

Danke für den Link Lucki

Anzeige

(29.05.2012 16:11 )Lucki schrieb:  Die fortschrittlichste Architektur überhaupt - von ch schon angedeuted - ist die Event-driven queued State-machine, siehe hier. Wenn Du alles noch mal überarbeitest, würde ich an Deiner Stelle so etwas machen.

Guten Morgen,

Wenn ich deinen Link richtig verstanden habe (sehr informativ und gut geschrieben!), dann eignet sich die State-Machine gut, wenn man mehrere verschiedene Abläufe hat, die alle in unterschiedlicher Reihenfolge mit unterschiedlichem Abstand aufgerufen werden können. Es kann also sein, dass der erste Task noch nicht fertig bearbeitet ist, während der zweite schon angewählt wird usw.

Dies ist bei mir jedoch nicht der Fall. Ich dachte bisher, ich nutze hier bewusst keine Puffer (ein Queue), da ich die parallele Datenverarbeitung von Labview nutzen möchte. Im Prinzip ist es mir völlig wurscht, ob er erst Analysator a oder b abfragt, wichtig ist nur, dass er jeden einmal anspricht bevor er einen das zweite Mal anspricht.

Könnt ihr mit diesen Informationen sagen, ob meine Einschätzung richtig ist, dass hier die State-Machine nicht sinnvoll ist? (Ich habe eine Übersicht angefügt.)

Bisher habe ich mich entschieden, die einzelnen Buttontätigkeiten vor der Messung durch eine Eventstruktur zu ersetzen, der Teil mit der Labelbeschriftung ist bereits in eine gewandert. Die Messprozedur kommt dann in das Event für den Button "Messung starten". Die Messung ansich bleibt aber dann parallel.

Ich hoffe auf Input. Auf das VI hat sicher keiner Lust.

Grüße,

(30.05.2012 08:52 )Takuro schrieb:  Ich hoffe auf Input. Auf das VI hat sicher keiner Lust.

Grüße,

Darf ich mir das VI mal ansehen? Interessiert mich schon wie man auf 10 Bildschirmgrössen kommt und deine Fragen lassen sich auch besser beantworten mit einem praktischen Beispiel.

Gruss Marc

Ich lad nur mal das Main VI hoch, die ganzen SubVis wären dann doch ein paar viele...

Man sieht ja trotzdem die Struktur.

(30.05.2012 10:49 )Takuro schrieb:  Ich lad nur mal das Main VI hoch, die ganzen SubVis wären dann doch ein paar viele...

Man sieht ja trotzdem die Struktur.

Ist passwortgeschützt Aber versteh ich das grundsätzlich richtig, du stellst in den verschiedenen Tabs deine Messwerte dar welche durch unabhängige (Datenmässig) Messungen erfasst wurden?

Gruss Marc