ElabNET Technik Forum

MiniMaxV2 hat geschrieben: ↑So Mai 03, 2020 6:17 pm Vereinfachung der Schaltkreise (KV-Diagramme)

Das waren noch Zeiten mit KV... schön wars

Genau. Natürlich gilt jede Variable vorher wie nachher.

Danke für die Hilfe.
Robert

Hallo Hans-Martin!

Du wolltest es so

MiniMaxV2 hat geschrieben: ↑So Mai 03, 2020 6:17 pm Und klar - immer her mit den Fragen

Hab nun das Zustandsdiagramm (falls man das überhaupt so nennt) nochmal gezeichnet und die Tabelle dazu fertiggestellt.
Jetzt ist mir auch klar, warum ich da bei der klassischen Programmierung noch ein paar Bugs hatte, den die Zustände sind doch komplizierter als erwartet.
Ich habe auch verstanden, dass jeder Zustand auf eine Änderung von SV und IN reagieren muss, damit keine State "hängen bleibt".

Was mich im Vergleich zu deinem Beispiel weiter oben interessiert: Warum ordnest du deinen Zustandsübergangstabelle nach den Bedingungen.
In meinem Fall habe ich diese der Reihe nach entsprechend den States geordnet.
Mit ist klar dass die Reihenfolge einer Priorisierung entspricht und vermute, dass das bei dir der Grund ist?

In jedem Fall habe ich an der State Machine Gefallen gefunden, auch wenn ich gerade erst begonnen habe.

lg
Robert

Hi Robert,
ich merke schon - du fängst an dich für Automaten zu begeistert. Das Ganze hat schon ne schöne Struktur und wir übersichtlicher. Was mir dabei ins Auge springt, du behandelst die "Timeouts" spearat. Sie gehören aber mit in die "Übergangsbedingung". Damit kannst du einfach die erste Spalte als Bedingung nutzen. Und vereinfachen tust das Ganze, indem du die Klauseln mit einem * streichst.

Was mir dann noch auffällt, dir fehlen da ein paar Übergänge (es sei denn, sie sind gekürzt, da sei keinen Übergang verursachen). z.B. bei der Ersten "Gruppe"- SV=1 & IN=0 sowie SV=1 & IN=1 (T_M=*, T_L=*) eingegeben. Aber was ist mit SV=0 & IN=0 sowie SV=0 & IN=1 ? Vielleicht hast du da ja schon implizit gedacht, dass dann der Zustand bleibt.


Zu deiner Frage mit der Reihenfolge - ich habe bei meinem Beispiel am Anfang die "Abbruchbedingungen" und danach die "normalen" Übergänge. Da gibt's natürlich auch ausnahmen, wenn aufgrund der Vereinfachung die Übergänge nicht Eindeutig ist aber einer die "Prio" bekommt.

Hy Hans-Martin!

Völlig richtig, bin begeistert.

Danke für die weiteren Erläuterungen. "Alles" klar.

Zum Hinweis mit den Timeouts: ist mir bewußt, dass das für die Übergangstabelle auch eine Bedingung ist, die Tabelle ist aufgrund des Eingabeformats in der TWS State Maschine so entstanden.

Danke und lg
Robert

Kleiner Nachtrag:
Es hatte schon einen Grund, dass ich die Timeouts separat hatte (und die Übergangsbedingung war ursprünglich auch leer).
Die Syntax des LE will bei Timeouts keine Übergangsbedingung sondern einfach eine 0.

lg
Robert

Hi Robert,
dann hab ich nicht verstanden, was du mit Timeout meinst
Hast du ein Beispiel?

Hy Hans-Martin!

Mit Timeout meine ich, dass ein Zustand nach einer gewissen Zeit automatisch in den nächsten wechselt, ohne dass sich SV oder IN ändern. zb im Posting 13 von 2 => 4.

Ich habe erst jetzt verstanden, dass der Timeout als Parameter beim Übergang in den nächsten Zustand, der zeitlich begrenzt sein soll, mitgegeben werden muss (was bei genauer Überlegung genial ist). D.h. damit der Zustand 2 zeitlich begrenzt wird, muss jeder Zustand der in 2 springt diesen Timer auch starten.

lg
Robert

Hi Robert,
ach du meinst den trigger timer, den die StateMachine im Wolf mitbringt? Jetzt hab ichs verstanden. Dieser ist ja keine "Bedingung" sondern einfach nur eine Angabe für einen automatischen Trigger. Das heißt, dass du den Timer startest, wenn du in den Zustand 2 gehst (0-2;1-2;3-2). Den darauf folgenden Übergang hast du ja dann noch eindeutig beschrieben durch In=1 und SV=1. Du wirst nur so das Problem haben, dass dir die Logik zu oft triggert. Wenn du z.B. vor dem Timer durch bist und sv=1 in=0 in Z3 geht vor dem Timer, kommt die Logik in den Übergang 3-6, was ja nicht gewollt ist. Kurz - die Zeiten im Automaten des Wolfs sind keine "Timeouts", es sind Auto-Trigger. Du wirst für deine Timeouts, die auch als solche definiert sind, separate Timer laufen lassen müssen, wo du erkennen kannst, ob der Timer oder ein anderer Eingang getriggered hat. Das führt dann im Beispiel dazu, dass der Timeout mit als Bedingung rein kommt und dann Sv=1 In=0 Timeout_Mähen=0 gilt und somit kein Übergang "passend" ist - die Statemachine bleibt im Zustand 3. Daher auch immer meine Beschreibung der "Timeouts" als Übergangsbedingung und nicht als AutoTrigger.

Hallo Hans-Martin!

Ich glaube da liegst du falsch.
S. Kolbinger hat es als Timeout beschrieben und es funktioniert auch genau so.
=> Übergangsbedingung 0 wertet den laufenden Timeout aus und triggers auch den Übergang in dieser Zeile.
(0,1,3,0) springt von 1 nach 3 wenn ein timeout beim Übergang in 1 gestartet wurde.
Läuft auch so bereits.

Lg
Robert