Gestaltungsfrage

Hallo Forum!

Vorerst möchte ich anmerken, dass ich noch relativ neu im ganzen LabVIEW-Thema bin.

Zu meiner/meinem Frage/Problem:
Ich möchte einen Motor ansteuern. Dabei soll der Motor zuerst eine von mir bestimmte Anzahl an Schritten pro Sekunde, in einem bestimmten Verfahrweg verfahren. Anschließend soll der Motor kurz stehen bleiben und danach einen weiteren Durchlauf machen. Dieser Vorgang soll 6 mal wiederholt werden. Ich möchte dabei jeweils eine unterschiedliche Anzahl an Schritten pro Sekunde, sowie am Verfahrweg einstellen.
Genau das habe ich auch soweit geschafft!
Für den Fall, dass eine Eingabe falsch getätigt wurde, würde ich gerne einen Stopp-Button einfügen, der egal in welchem Moment den Case schließen würde.
Nun habe ich einem Eintrag gelesen, dass ich einen Case nicht vorzeitig beenden kann.
Habt Ihr eine Idee, wie ich mein Programm anders gestalten kann, dass es so funktionieren würde?
Falls es jedoch eine Methode gibt den Case vorzeitig zu beenden, würde ich mich darüber natürlich auch sehr freuen.

Zwei Screenshot füge ich bei!
Zum besseren Verständnis: Rechts von 1. Screenshot werden die Daten erneut abgefragt. Quasi 5 mal copy/paste.

Das Programm habe ich in Form einer State-Machine erstellt.

Ich bedanke mich im Voraus für jede einzelne Antwort!

Beste Grüße

Hallo Smith,

herzlich willkommen im Forum!

Zitat:Nun habe ich einem Eintrag gelesen, dass ich einen Case nicht vorzeitig beenden kann.

Korrekt: THINK DATAFLOW!
Bedeutet: es muss erst der Inhalt der Case-Struktur abgearbeitet sein, bevor der Case verlassen wird…

Zitat:Habt Ihr eine Idee, wie ich mein Programm anders gestalten kann, dass es so funktionieren würde?

Programmiere deine Statemachine noch etwas "sauberer".
Und versuche, noch "kleinere" States zu definieren: wenn der einzelne State nicht so lang dauert, kannst du ihn nämlich auch leichter/schneller beenden!

Zitat:Zum besseren Verständnis: Rechts von 1. Screenshot werden die Daten erneut abgefragt. Quasi 5 mal copy/paste.

Bei "5mal copy&paste" kräuseln sich die Zehennägel…

Hallo Gerd!

Vielen Dank für die Antwort!

Zitat:Korrekt: THINK DATAFLOW!
Bedeutet: es muss erst der Inhalt der Case-Struktur abgearbeitet sein, bevor der Case verlassen wird…

Das ist natürlich schade, aber hab ich mir jetzt auch schon gedacht.

Zitat:Programmiere deine Statemachine noch etwas "sauberer".
Und versuche, noch "kleinere" States zu definieren: wenn der einzelne State nicht so lang dauert, kannst du ihn nämlich auch leichter/schneller beenden!

Was genau meinst du damit? Das Problem mit der Zeit ist einfach, dass bevor der Motor den nächsten Befehl ausführen soll, erst einmal der vorherige komplett beendet werden muss. Daher habe ich auch die ganzen Wait-Einträge. Außerdem hatte ich zu Beginn das Problem, dass mein Programm nur im Highlight-Modus funktioniert hat. Nach einiger Recherche habe ich herausgefunden, dass die einzelnen Einträge zu schnell durchlaufen und ich einfach dazwischen Wait-Einträge brauche.

Zitat:Bei "5mal copy&paste" kräuseln sich die Zehennägel…

Hättest du da eine bessere Idee ? Bin über jeden Vorschlag glücklich.
Um vielleicht mein Programm noch ein wenig besser zu beschreiben. Ich habe 6 verschiedenen Durchläufe drin, weil ich auch entscheiden möchte, ob ich den Motor 1, 2, 3 ... usw. Male anspreche.

Beste Grüße

Hallo Smith,

Zitat:Was genau meinst du damit? Das Problem mit der Zeit ist einfach, dass bevor der Motor den nächsten Befehl ausführen soll, erst einmal der vorherige komplett beendet werden muss.

Ich meine damit, dass du die States "feinkörniger" definieren solltest!

Aus "Fahre den Motor 3mal hin und her" werden dann z.B. die States:
- setze Motor-Parameter1
- setze Motor-Parameter2
- starte Motor
- Warte x Millisekunden
- stoppe Motor

Der eine "große" State braucht vorher vielleicht 30s, jeder einzelne "kleine" State aber nur noch 1s. Und nach jedem State kann man die Abbruchbedingung erneut testen: im Beispiel also 30mal öfter…

Wenn man es noch feiner/manipulierbarer braucht:
Man kann das ganze auch aus einer reinen Statemachine in einen QMH (Queue Message Handler) umwandeln: der Handler nimmt Messages (=States) aus einer Queue entgegen und arbeitet diese ab. Jetzt kann man
1. Beliebig viele Befehle (=States) in die Queue hineinschieben (z.B. den kompletten Prüfablauf)
2. Man kann mittendrin am "vorderen" Ende der Queue Befehle dazwischen schieben
3. Man kann die Queue (im Notfall) komplett leeren und z.B. den "Notfall-STOP"-Befehl stattdessen hineinschieben…

Grundprinzip:
Wenn du möglichst schnell auf User-Interaktion reagieren möchtest, musst du den Unterbau deines Programmes darauf vorbereiten - das schließt eben Routinen aus, die lange laufen und nicht unterbrochen werden können…

Hallo Gerd,

Zitat:Ich meine damit, dass du die States "feinkörniger" definieren solltest!

Ich werde mal probieren es in kleinere "Portionen" aufzuteilen, die ich anders ansprechen kann.

Zitat:Man kann das ganze auch aus einer reinen Statemachine in einen QMH (Queue Message Handler) umwandeln: der Handler nimmt Messages (=States) aus einer Queue entgegen und arbeitet diese ab.

Davon habe ich noch nie etwas gehört. Es klingt aber relativ gut! Ich werde mich da mal reinlesen.

Bis dahin Beste Grüße.