HS/FS Wie geht man vor: Zustandsmaschinen für HS ?

[knxfindichgut]

Hallo Forum,

ich bin seit einigen Tagen dabei in unser Haus Eigenleben einzuhauchen, sprich die Logiken für den HS3 zu programmieren. Dabei stehe ich vor dem generellen Problem, wie ich Zustandsmaschinen am besten in die Logik-Editor Syntax verwandeln kann.
Ich tue mir leicht in Statemachines (SM) zu denken, aber wie implementiert man so etwas effektiv im HS3 ?

Anbei eine SM für eine Anwesenheitssteuerung, ist nur ein erster Entwurf, d.h. sicherlich noch nicht ausgereift. Aber für ein How-To mit Erfahrungen der Forenmitglieder reicht es allemal.

Man sieht nummerierte Zustände und Übergange. "Aktionen" werden durch einen Slash (/) von der Übergangsbedingung getrennt. Sind die Übergänge nummeriert (z.B: 1: ...) ist die Priorität wichtig.
Ich kann mir vorstellen daß ich alle Übergänge einzeln mit UND/ODER,... Gattern implementiere wobei jeweils das Ergebnis "wahr" ist wenn der Zustandsübergang erfüllt sein soll.

Soweit sogut.
Jetzt aber die Frage: Wie bilde ich die Zustände nach ? Welche Logikbausteine würdet ihr nehmen bzw. wie geht man so etwas generell im GLE an ? Die Dacom beiden "Statusmaschinen" Bausteine eignen sich
dafür eher nicht, oder täusche ich mich ?

Ich bin wirklich über jeden Ratschlag oder besser noch Beispiele dankbar.
Grüße, Stefan

[SebastianFey]

Der HS ist dafür schlecht geeignet.
Evtl so:

- ein IKO für den state (dieses darf die Logik nicht triggern!)
- ein IKO für den event (Änderungen der event-IKO triggern die Logik, müssen von anderen Logiken generiert werden)

Die Logik prüft dann zuerst das state-IKO, darin dann das event-IKO, hier kommt dann die action hin, evtl Zustandsänderung (diese darf die Logik nicht triggern, s.o.).

Also ähnlich der C-Implementierung hier:
Event-driven finite-state machine - Wikipedia, the free encyclopedia

[gaert]

Warum sollte das mit dem HS nicht gehen?! Ähnliches mache ich an vielen Stellen in der Logik. Mit Gattern, Sperren und Zeitfunktionen kann man so einiges lösen!

Man muss natürlich immer im Hinterkopf haben, dass der HS Eventgesteuert agiert - also vergleichbar mit objektorientierten Programmiersprachen. Sequentielle Programmabläufe sind nur umständlich zu implementieren (z.B. per Sequenz).

Dennoch dürfte eigentlich so ziemlich jede Problemstellung zu bewältigen sein. Wenn Du eine etwas konkretere Frage (vielleicht auf einen Teil Deines Vorhabens beschränkt) hast, helfe ich gerne.

[SebastianFey]

Warum sollte das mit dem HS nicht gehen?!

Sagt doch keiner, es ist nur nicht komfortabel umzusetzen mit dem HS.

Ähnliches mache ich an vielen Stellen in der Logik. Mit Gattern, Sperren und Zeitfunktionen kann man so einiges lösen!

Sicher, mit einer Turingmaschine kann man auch "so einiges lösen", die Frage ist nur wie komplex die Lösung wird.

Man muss natürlich immer im Hinterkopf haben, dass der HS Eventgesteuert agiert - also vergleichbar mit objektorientierten Programmiersprachen.

was der GLE des HS mit einer OO Sprache zu tun haben soll, erschliesst sich mir nicht.

[gaert]

was der GLE des HS mit einer OO Sprache zu tun haben soll, erschliesst sich mir nicht.

Der GLE gar nichts, aber die interne Verarbeitung der Logik auf dem HS so einiges.

[2ndsky]

Wie geht man vor: Zustandsmaschinen für HS ?

Event driven hat aber dennoch nichts mit Objektorientierung zu tun

[Axel]

Über den HS GLE simpelst abbildbar. Ähnliche Konfiguration ist eigentlich Standard. Du hast 5 Zustände. Also 5 Ausgänge. Die Ausgänge werden über UND angesteuert mit vorgelagerter Auswertung. Fertig. Mit Standard Gattern no Problem.

Gehe einfach von hinten nach vorne. Sprich Ausgang abwesend soll passieren wenn xyz.

[gaert]

Event driven hat aber dennoch nichts mit Objektorientierung zu tun

Sorry, aber OO ist ausschließlich Ereignisgesteuert... Das ist doch das Grundprinzip der OO-Idee.

[2ndsky]

Wie geht man vor: Zustandsmaschinen für HS ?

Sorry, aber OO ist ausschließlich Ereignisgesteuert... Das ist doch das Grundprinzip der OO-Idee.

Sorry, aber das Grundprinzip von OO hat sowas von überhaupt nichts mit event driven zu tun. Oberflächen programmiert man event driven, dazu brauch ich aber kein OO. Das kann ich auch in der WinAPI die rein auf C basiert machen und C kann kein OO.

Weiterführende Infos
http://de.m.wikipedia.org/wiki/Objek...Programmierung
http://en.m.wikipedia.org/wiki/Event-driven_programming

[knxfindichgut]

Guten Morgen,
danke für eure Antworten. Also wenn ich es richtig verstehe dann ist die best-practice eher daß man pro Zustand ein iKO hat also x Ausgänge (siehe Antwort von Axel). In meiner Vorstellung hatte ich eher "klassisch" gedacht, also ein einziges iKO welches die Nummer des Zustandes hält und eben durch Events diese Zahl änder.
Davon also eher verabschieden ?

Axel, habe verstanden was du meinst, nur was bedeutet "Die Ausgänge werden über UND angesteuert" ? Ich stelle es mir so vor daß sozusagen daß iKO des VORHERIGEN Zustandes (bool) immer auch in die Logik für den folgenden Zustand mit eingeht (AND) ?

An SebastianFey: das klingt auch interessant, hast du vielleicht ein Beispiel aus einem deiner GLE Entwürfe ?

viele Grüße !

[SebastianFey]

Über den HS GLE simpelst abbildbar. Ähnliche Konfiguration ist eigentlich Standard. Du hast 5 Zustände. Also 5 Ausgänge. Die Ausgänge werden über UND angesteuert mit vorgelagerter Auswertung. Fertig. Mit Standard Gattern no Problem.

Gehe einfach von hinten nach vorne. Sprich Ausgang abwesend soll passieren wenn xyz.

Wenn ich dich richtig verstehe schlägst du eine einfache "wenn->dann"-Logik vor.

Das ist aber *nicht* das was der OP aufgemalt hat. Im Gegensatz zum "wenn->dann" (event-action) hat er einen Zustandsautomaten aufgebaut.

Hier ist die Reaktion auf ein Ereignis immer auch vom aktuellen Zustand des Systems abhängig. Du musst also immer fragen: 1. In welchem Zustand bin ich 2. welches Ereignis ist eingetreten. In diesem Zweig wird dann eine Aktion ausgeführt und optional der Zustand geändert.