Wie macht man am geschicktesten Initialisierungen?
Ich habe jetzt eine while-Schleife und einen Eventcase dadrinnen. Bevor der Prozess beginnt, sollen erstmal Initialisierungen erfolgen, wie Zuweisung von irgendwelchen Standard-Daten, Farben, Eigenschaften von was auch immer.
Ist es in so einem Fall sinnvoll, eine Sequenz zu nehmen? Oder einfach einen zweiten Fehler-Case einführen und die Reihenfolge der Ausführung durch den Fehlercluster vorgeben? Weil ich habe mal irgendwo gelesen, dass man wenn möglich ohne Sequenzen arbeiten soll.
Meine bisherige Lösung war ein Schleifendurchlauf in einer for-Schleife, die genau einmal gemacht wird - wie in dem Bild, dass halte ich aber für schlecht und aus dem Bauch heraus würde ich die for-Schleife einfach durch einen weiteren Fehlercase ersetzen.
Vielleicht gibt es aber auch noch andere Möglichkeiten.
Ich könnte auch die Zuweisung der Ini-Daten irgendwie in der Haupt-while-Schleife machen, aber warum sollen irgendwelche Zuweisungen bei jedem Schleifendurchlauf erneut gemacht werden - das halte ich für eher ungünstig.
Hallo Hasenfuss,
was gibt es an Sequenzen (gestapelten wohlgemerkt) auszusetzen. Das mit der einmal durchlaufenden Schleife in Verbindung mit shift-Registern kann man in Sub-VIs machen, um Startwerte über die Lebenszeit der Applikation zu speichern.
Gruß, Marko
Eine, meiner Meinung nach saubere, Lösung wäre eine Statemachine in der While-Schleife. Da kannst du dann auch evtl. Fehlerbehandlung mit reinpacken.
(23.01.2013 18:48 )L@bRAT schrieb: [ -> ]Eine, meiner Meinung nach saubere, Lösung wäre eine Statemachine in der While-Schleife. Da kannst du dann auch evtl. Fehlerbehandlung mit reinpacken.
Hmm - mag ja sein. Aber in welches Event soll man Initialisierungen bei einem Zustandsautomanten machen? Ich habe ja jetzt bereits einen Zustandsautomat, aber dort werden nur die Cases ausgeführt, die ich mit einem Ereignis gekoppelt habe.
Wenn ich jetzt einen Button mache - Initialisieren, dann könnte ich das Event bearbeiten und da die Initialisierungen machen. Alternative - es müsste ein Event geben, dass einmalig ausgeführt wird, in das kann ich die Initialisierungen reinpacken. Aber so ein Event kenne ich bis jetzt noch nicht.
Hallo Hasenfuss,
Zitat:Ich habe ja jetzt bereits einen Zustandsautomat, aber dort werden nur die Cases ausgeführt, die ich mit einem Ereignis gekoppelt habe.
Jein...
Du hast eine Event-Struktur, die auf User-Input wartet und einen Wert ausgibt, der in einem nachfolgenden Case ausgewertet wird. Eine "echte" Statemachine ist das noch nicht...
Vorschlag für dein gezeigtes VI:
- Erstelle in der While-Loop ein Schieberegister (SR) für den Case/State.
- Initialisiere dieses SR mit "Init".
- Führe in der While-Loop als erstes (!) die Case-Struktur aus, die den State auswertet
- Erst danach kommt die Event-Struktur zum Zuge, die wiederum den nächsten State ausgibt und an das SR weiterreicht...
Zitat:es müsste ein Event geben, dass einmalig ausgeführt wird, in das kann ich die Initialisierungen reinpacken. Aber so ein Event kenne ich bis jetzt noch nicht.
Es gibt User-defined Events (und Beispiele dazu im Examplefinder) als auch per "Value signaling"-Propertynode ausgelöste Events. Erstelle dir ein (evtl. unsichtbares) Control namens Init und löse für dieses per Propertynode ein ValueChange-Event aus...
Danke für Eure Beiträge.
Habe also jetzt das mal etwas abgewandelt, und eine whileSchleife mit Schieberegister gemacht. Daran hängt auch ein enum. Der erste Wert im Schieberegister wird durch das enum mit Init vorgegeben, dann wird der Init-Case ausgeführt. Dort kann ich dann jegliche Art von Initialisierungen machen.
Jetzt will ich als aller erstes ein Event auslösen, dass auf einen Stopp-Button reagiert und dann dazu führt, dass der Stopp-Case (auch ein Wert in dem enum) ausgeführt wird.
Dazu habe ich nun innerhalb der while-Schleife ein Ereignis-Case eingebaut. Time-Out ist vorhanden und wurde auf -1 gesetzt, dann der Ereignis-Case, der auf den Button reagiert. Nun msste ich wie in dem zweiten Bild den Inhalt des Ereignieses auch mit in den Schieberegister mit reinbringen.
Was hab ich jetzt gemacht - jetzt habe ich praktisch einen Mischmasch erzeugt - es könnten weitere Zustände durch die case-Struktur vorgegeben werden und in dem Ansatz nun auch noch parallel dazu durch den Ereignis-Case. Kann man so "gemischt" arbeiten oder geht das garnicht bzw. sollte man entweder nur "von case zu case-basiert" arbeiten oder nur von event-case zu auswerte-case?
Was ich nun auch nicht weis - würde die while-Schleife weiterarbeiten oder stoppen, so lange bis der Ereignis-Case abgearbeitet ist, da ja der timeout-ereignis-case bei -1 in dem Beispiel gesetzt ist?
In einem Buch habe ich gerade noch eine andere Variante gesehen. Dort ist der Event-Case in einer separaten while-Schleife untergebracht. Dann wird mit einer Queue gearbeitet - mit der Queue könnte ich wahrscheinlich das Problem lösen, was ich in dem aktuellen Beispiel hab, wo ich die beiden Pfeile gezeichnet habe - nämlich wie ich nun die beiden Signalstränge miteinander koppele, damit auch das Ereignis-case dann in dem auswerte-Case abgearbeitet wird.
Würdet ihr jetzt einen Zustandsautomaten, der auch auf Events reagieren soll zu einem parallen "normalen" case in einem Zustandsautomaten realisieren? In dem "normalen" case hab ich noch einen Datenstrom an einen Schieberegister gekoppelt, mit dem ich dann noch irgendetwas machen kann - irgendwelche Werte von Zustand zu Zustand durchreichen oder so?
Hallo Hasenfuss,
Zitat:Was ich nun auch nicht weis - würde die while-Schleife weiterarbeiten oder stoppen, so lange bis der Ereignis-Case abgearbeitet ist, da ja der timeout-ereignis-case bei -1 in dem Beispiel gesetzt ist?
Ersten sieht man das sehr gut beim Debugging mit aktiviertem Highlighting und zweitens gilt immer noch der
DATAFLOW!