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…
