Hallo Nowhere,
Zitat:m Moment läuft ja alles stupide einer vorgegebenen Reihenfolge ab.
Weil
ihr einen festen Ablauf programmiert habt. Ihr habt zwar States definiert, aber bei euch fehlt ja noch komplett eine Abfrage von Übergangsbedingungen!
Z.B.: Soll jetzt mit dem dem "normalen" Ablauf weitergemacht werden oder soll etwas anderes (wie Fußgängerschaltung) gemacht werden?
Zitat:Wenn ich also mitdrin einen Nachtmodus rein setzte, wird doch der Ablauf gestört. Oder Nicht?
Der bisherige starre Ablauf wird gestört - aber den wollt ihr doch überhaupt nicht haben!
Ihr wollt doch anhand irgendwelcher Bedingungen entscheiden können, welcher State als nächstes dran ist…
Zitat:Was ich damit eigentlich meinte: wie bringe ich die Gelbe LED im Cluster im Nachtmodus zum blinken ohne das ich den Cluster zerlegen muss um an die Gelbe LED zu kommen???
Wenn du etwas "meinst", dann solltest du das auch schreiben
Zu den Clustern:
- alle Cluster sollten typdefiniert sein, alle Elemente im Cluster sollten ein aussagekräftiges Label haben!
- die Cluster speichern deinen aktuellen Zustand: da du den evtl. auch im nächsten State (d.h. nächste Iteration) brauchst, gehören diese Cluster in Schieberegister!
Blinken ist dann einfach: aktuellen Zustand (d.h. Cluster) lesen, per UnbundleByName die "GELB"-LED rausholen, negieren und wieder mit BundleByName in den Cluster schreiben. (Oder man nimmt eine Inplace-Struktur…)
Beispiel:
Das Enum
sollte muss auch typdefiniert werden, und dann überall eine Instanz dieser Typdefinition verwenden!
Die Items im Enum dürfen gern auch aussagekräftigere Bezeichnungen haben als nur "Phase1"-"Phase8", z.B. "Fußgänger an", "Auto Rot", "Auto Rot-Gelb", "Nachtschaltung", etc.…
Außerdem: Das Label von FP-Elementen zu löschen ist GANZ SCHLECHTER Programmierstil!