Hallo zusammen, es geht bei meiner Frage zwar nicht direkt um PC-Programmierung, aber ich denke, das Thema passt am besten in dieses Forum. Momentan bin ich dabei die Software (Assembler) für ein Modul meines Hausbusses zu schreiben. Konkret soll das Modul im Aussenbereich Tür und Rolltor der Hauseinfahrt überwachen sowie die Lichtsteuerung dort übernehmen. Es gibt 8 Eingangsgrößen, welche jeweils durch ein Bit repräsentiert werden: 1) Magnetkontakt obere Endlage Rolltoor 2) Magnetkontakt untere Endlage Rolltoor 3) Magnetkontakt Tür 4) Sabotageschleife aller 3 Magnetkontakte in Reihenschaltung 5) Stromerkennung Motor Rolltor 6) Bewegungsmelder Torinnenseite 7) Bewegungsmelder Toraussenseite 8) Helligkeitssensor Ausgangsgrößen gibt es drei: Licht innen, Licht aussen und einen Signalgeber (Alarmsirene o.ä.) Das Modul funktioniert soweit einwandfrei, d.h. die 8 Eingangsgrößen werden erfasst und die 3 Aktuatoren können betätigt werden. Nun mein Problem: Wie verknüpfe ich die Eingangsgrößen mit den jeweiligen States im Modul? Ein State könnte z.B. die Unterscheidung von Tag und Nacht sein oder ein anderer, ob die Objektüberwachung (Alarmanlage) aktiv ist oder nicht. Bei einer State-Machine ergeben sich 256 mögliche Kombinationen aus den obigen 8 Eingangsgrößen. Nur wie verknüpft man die sinnvoll? So ist z.B. der Sabotagekontakt bei der Unterscheidung Tag/Nacht ohne Bedeutung, wenn die Alarmanalge aktiv ist, aber schon. Der innere Bewegungsmelder hingegen kann sowohl das Licht betätigen, als auch ggf. einen Alarm auslösen. Der Helligkeitssensor hat einen Einfluss auf das Einschalten des Lichts, ist aber unabhängig von der Alarmanlage. Da ergeben sich zig Abhängigkeiten. Mir geht es nicht um Implementierungsdetails, mehr um ein generelles Verständnis. Geht man bei der Definition der States nach einer Art Hierarchie vor oder gibt es grundsätzliche Regeln? Wenn jemand dazu sachdienliche Anregungen, Links, gerne auch Literaturtips hat, wäre ich sehr dankbar! MFG Andy
Hm. Man wird das nicht erschöpfend beantworten können, ohne an Deiner Stelle die State-Machine zu entwerfen (nicht zu definieren - das ist etwas anderes). Es stellt sich aber, nach Deiner Beschreibung ohnehin die Frage ob eine State-Machine überhaupt notwendig ist. Alle Abhängigkeiten, die Du genannt hast, sind rein kombinatorisch von den Eingangsgrössen abhängig, nicht aber davon, dass bestimmte Eingangsgrössen früher einmal bestimmte Werte hatten, als sie in den von Dir genannten hypothetischen Zuständen aktuell haben. Es ist übrigens zwar dennoch möglich, bei rein kombinatorischer Abhängigkeit, diese als State-Machine zu beschreiben, aber es ist nicht nötig und kompliziert die Dinge für einen Anfänger nur unnötig. Du wirst das evtl. noch nicht verstehen, aber ich rate Dir zunächst einmal zu versuchen, die Ausgangsgrössen ausschliesslich als von den jeweils gegenwärtigen Eingangsgrößen abhängig zu betrachten - und nicht auch noch von der Vorgeschichte dieser Eingangsgrössen. Das entsprechende Paradigma dazu heisst "Entscheidungstabelle" (so wie die State-Machine ein Paradigma ist). Ein gutes Hilfsmittel dazu, dass dazu noch fast jeder Computerbenutzer haben dürfte, ist ein Spreadsheet bzw. Rechenblatt-Programm, wie etwa Microsofts "Excel" bzw. LibreOffices "Calc". Es gibt auch unter dem Stichwort "Entscheidungstabelle" einige Vorlagen, die unter anderem helfen, alle möglichen Kombinationen zu berücksichtigen. Das geht aber bei 8 Eingangsgrössen durchaus noch von Hand. Beschäftige Dich einmal damit - dazu gibt es unzählige Beschreibungen im Internet. Erst wenn und falls Du feststellst, dass für Deine Anwendung auch die Vorgeschichte der Eingangssignale eine Rolle spielt - oder, in anderen Worten, es mindestens zwei Fälle gibt, in denen bei gleichen Eingangssignalen unterschiedliche Ausgangssignale erzeugt werden sollen, ist eine State-Machine überhaupt notwendig. Dann aber lies Dich einmal ein wenig in solche State-Machines ein. Dann kannst Du auch spezifischere Fragen stellen.
Hallo Theor, Danke für das ausführliche Feedback! Ich hoffe, meine Erklärungen waren nicht missverständlich. Bei Modulen mit Display nutze ich bereits eine State-Machine, d.h. bei jeder Transition wird ein spezifische Aktion durchgeführt. Das ist für die Menüführung mit einer beschränkten Anzahl von Bedienknöpfen nützlich/zwingend. Nur ist mir nicht klar, wie ich das in dem geschilderten Anwendungsfall (sinnvoll) umsetze. Du hast Recht, vielleicht gibt es hier nicht wirklich Abhängigkeiten von den vorherigen Zuständen. Zum Stichwort Entscheidungstabelle und State-Machines werde ich mich auf jeden Fall noch einmal ausführlich informieren. MFG Andy
Andy W. schrieb: > Ein State könnte z.B. die Unterscheidung von Tag und Nacht sein oder ein > anderer, ob die Objektüberwachung (Alarmanlage) aktiv ist oder nicht. Was du beschreibst, ist kein State. Ein State (zu deutsch: Zustand) ist keine Unterscheidung, sondern eben ein Zustand, in dem das System gerade ist. Eine Statemachine ist zu jeder Zeit dann in einem (und genau einem) ihrer Zustände. Auch Tag und Nacht sind eigentlich keine Zustände, sondern eher Inputs. > Bei einer State-Machine ergeben sich 256 mögliche Kombinationen aus den > obigen 8 Eingangsgrößen. Die Besonderheit einer Statemachine ist, dass abhängig von ihrem aktuellen Zustand die Eingangssignale unterschiedlich behandelt werden können. Es sind also mehr Kombinationen, da der Zustand noch mit eingeht. Die Eingangssignale lösen dabei Übergänge zwischen den Zuständen aus. > Nur wie verknüpft man die sinnvoll? > So ist z.B. der Sabotagekontakt bei der Unterscheidung Tag/Nacht ohne > Bedeutung, wenn die Alarmanalge aktiv ist, aber schon. Da sehe ich keine Statemachine, sondern einfach eine boolesche Verknüpfung. Wie Theor schon schrieb, ist das eher ein kombinatorisches Problem. > Der innere Bewegungsmelder hingegen kann sowohl das Licht betätigen, als > auch ggf. einen Alarm auslösen. Aber auch hier sehe ich eine einfache Verknüpfung: WENN Alarmanlage an UND Bewegung registriert, DANN Alarm WENN Alarmanlage aus UND Bewegung registriert, DANN Licht an > Mir geht es nicht um Implementierungsdetails, mehr um ein generelles > Verständnis. Geht man bei der Definition der States nach einer Art > Hierarchie vor oder gibt es grundsätzliche Regeln? Bei einer Statemachine gibt es keine Hierarchie, allerdings kann man mehrere Statemachines verschachteln. Es geht bei einer Statemachine in der Regel eher um einen Ablauf, der je nach Inputs unterschiedlich sein kann.
Deine Menge der Statusse ergibt sich aus den gültigen Zuständen deines Systems. Diese Menge musst du für dein System definieren. Und da schließen sich bestimmte Aktionen bzw. Zustände schon aus, so dass diese Statusmenge schon wesentlich kleiner ist, als die Kombinationen aller Sensor- und Aktorenzustände. Z.B. gibt es keinen Zustand, in dem der Helligkeitssensor Tag=hell meldet und die Hoflampe angeschaltet ist. Und z.B. spielt die Helligkeit im Zustand "Tor wird geschlossen" keine Rolle. Du solltest dir mal Gedanken machen, in welchen Zuständen das System sein kann. Mir fielen jetzt mal beispielhaft solche Zustände ein, wie z.B. "Tag, Tor offen", "Tag, Tor zu", "Nacht, Tor zu", "Tor wird geschlossen", "Tor wird geöffnet" usw. Diese Zustände verbindest du mit Aktionen. Z.B. gibt es zwei Übergänge von "Tag, Tor offen" zu "Tor wird geschlossen". Der erste Übergang ist, wenn jemand einen Taster "Tor schließen" drückt, der andere, wenn der Helligkeitssensor meldet, dass es dunkel wird.
Andy W. schrieb: > Nun mein Problem: Wie verknüpfe ich die Eingangsgrößen mit den > jeweiligen States im Modul? Kurze Antwort: die States einer State-Machine sind logische Zustände in zeitlicher Abfolge, wie etwa bei einer Datenübertragung Start, Daten, Prüfsumme, Ende. Solche States hat dein System garnicht, also brauchst du auch keine State Machine. Soweit aus deiner Beschreibung ersichtlich gibt es nur direkte logische Verknüpfungen der Art if Input 1 AND Input 3 then Output 5 = 1 else Output 5 = 0. Die brauchst du ja nur hinzuschreiben und in einer Endlosschleife ausführen. Georg
Andy W. schrieb: > Hallo Theor, > > Danke für das ausführliche Feedback! > > Ich hoffe, meine Erklärungen waren nicht missverständlich. > > Bei Modulen mit Display nutze ich bereits eine State-Machine, d.h. bei > jeder Transition wird ein spezifische Aktion durchgeführt. Das ist für > die Menüführung mit einer beschränkten Anzahl von Bedienknöpfen > nützlich/zwingend. Nun gut. Du benutzt das Schema einer State-Machine also schon in einem Fall. In einem Menüsystem ist das sicher nützlich, da bin ich Deiner Meinung. Ob es zwingend notwendig ist kann man aber definitiv feststellen und braucht sich nicht auf seine Meinungen zu verlassen. Ich denke aber, das ist hier nicht der springende Punkt, sondern der ist lediglich Deine Mitteilung, dass Du mit State-Machines schon zu tun hattest. > Nur ist mir nicht klar, wie ich das in dem geschilderten Anwendungsfall > (sinnvoll) umsetze. Du hast Recht, vielleicht gibt es hier nicht > wirklich Abhängigkeiten von den vorherigen Zuständen. OK. Es scheint mir, als wenn es um den gedanklichen Übergang von der State-Machine eines Menüsystems zu dem einer Steuerung geht und das Dir insbesondere die notwendigen impliziten Annahmen, die Du treffen musst, Schwierigkeiten bereiten. Ich vermute mal, Du denkst dabei öfter mal sowas wie: "Hm. OK. Also dann ist das so ... Aber dann müsste doch ... Aber das ist ja dann anders, als ... Aber, wie denn nun?" und es fällt Dir schwer eine Ordnung da hinein zu bringen. > Zum Stichwort Entscheidungstabelle und State-Machines werde ich mich auf > jeden Fall noch einmal ausführlich informieren. > > MFG > Andy Das ist gut. Ich möchte Dir noch einen Rat geben, wenn Du magst. Du fragst insbesondere danach, wie Du so eine State-Machine entwirfst. Obwohl Du Dich sicher noch etwas mehr informieren solltest (wie Du ja auch vorhast) kann man da durchaus einen, allerdings etwas lakonisch klingenden Rat geben. Nämlich: "Fange am Anfang an". Da gibt es aber zwei! :-) Ja. Zwei Anfänge. Das scheint etwas überraschend, ist aber sinnvoll so zu betrachten. Nämlich den Anfangszustand der äusseren Situation und den Anfangszustand der Steuerung. Die "äussere Situation" ist erstmal die der Bewegungsmeldern in Abhängigkeit davon, ob sich ein Fußgänger oder ein Auto in deren Erfassungsbereich bewegt (oder befindet, je nachdem wie der Melder funktioniert). Überlege Dir zuerst einmal einen Entwurf einer Zustandsmaschine für die Situation von Garagentor, Bewegungsmelder usw. Also nicht mit der Maschine der Steuerung beginnen, sondern mit den Abläufen in der Anordnung, die das Subjekt der Steuerung ist. Was ist der Anfang der Situations-State-Machine? Das ist vielleicht Sonntag nacht, wenn keiner unterwegs ist, das Auto in der Garage steht und Du schlummernd im Bett liegst. Letztlich ist der Anfangszustand willkürlich, aber es hilft eine reale Situation zu wählen. Und am Ende des Enwurfs steht die Prüfung, ob Du alle möglichen Zustände der "Eingänge" der Situations-State-Machine berücksichtigt hast. Was hilft Dir das aber nun? Das hilft Dir zu kontrollieren, ob Deine Steuerungs-State-Machine auch wirklich alle relevanten realen Zustände der Situation berücksichtigt, die "relevanten" von den "irrelevanten" (weil garnicht real auftretenden) Zustände zu unterscheiden und zu kontrollieren ob die Steuerung auch wirklich sinnvoll auf jede Änderung der äusseren Situation reagiert. Was ist der "Anfang" der Steuerungs-State-Machine? Das ist im einfachsten Fall, der Aus-Zustand. Natürlich kann von diesem Zustand durch keinerlei Änderung der Eingangssignale ein anderer Zustand erreicht werden - das kann nur durch das Einschalten geschehen. Aber es ist ein Anfang. Definitiv! :-) Nun, stell Dir vor, Du schaltest die Steuerung ein. Dann ist sie in einem der Ein-Zustände. Ich sage absichtlich "einem der", weil der Zustand nach dem Einschalten nicht ausschliesslich von dem Fakt, dass die Steuerung mit Strom versorgt wird, abhängt. Er hängt schon im ersten Schritt von den Zuständen der Eingangssignale ab. Und die ergeben sich aus den Überlegungen zu den Zuständen der Situation. Man muss berücksichtigen, dass die Steuerung ja in jeder der möglichen realen Situation eingeschaltet werden kann. Welche reale Situationen es gibt, kannst Du aber feststellen in dem Du die Situation erstmal modellierst. Das könntest Du Dir mal etwas detaillierter Überlegen. Vielleicht hilft Dir das weiter.
@ Andy Ah. Sorry. Ich vergaß zu erwähnen: Du solltest trotz meiner Informationen in meinem vorherigen Beitrag prüfen, ob die Abhängigkeiten nicht doch rein kombinatorisch sind, bevor Du von einer State-Machine für die Steuerung ausgehst. Aber die Situation kannst Du durchaus vorher mal modellieren. Das übt und ist auch noch einigermßen übersichtlich, weil die Anzahl der Input geringer ist. Auch kannst Du so Fehlerzustände gut deutlich machen; also solche, die Du im ersten Moment als "Unmöglich" bezeichnen würdest.
Rolf M. schrieb: > Es geht bei einer Statemachine in der Regel eher um einen Ablauf Noch nicht ganz: es geht um die Definition der Zustände (Knoten) eines (oft endlichen) Automaten und der Übergänge zwischen diesen (Kanten). Durch Kantenbewertungen oder Richtungseinschränkungen gibt das schöne Graphen und jede Menge theoretisches Beiwerk, Vorlesungen zu füllen. Man kann dann analysieren, wie man zwischen den Zuständen wechseln kann oder ob formale Paradigmen erfüllt/ nicht erfüllt sind. Einen Ablauf kann ich auch mit einem Programmablaufplan, einem UML-Sequenzdiagramm oder Pseudo-Code bewerkstelligen, um den Preis der Formalisierung aller Zustände und ihrer Übergänge. Welche Fragen hast du genau zum Beispiel aus dem Artikel zur Statemachine?
:
Bearbeitet durch User
Hallo zusammen, vielen Dank für Eure ausführlichen Rückmeldungen! Vielleicht sollte ich noch ein paar Infos liefern, damit mein Anliegen klarer wird: Die von mir verwendeten State-Machines haben eine tabellarische Form, ein Zahlenpaar pro Input und State, wobei eine Ziffer die beim Übergang ausgefürte Routine indiziert und die andere den nächsten State. Da ein gedrückter Button eine einfache Eingangsgröße ist, ist das für Menüs mit der Tabelle noch halbwegs überschaubar (z.B. 5Buttons=5Inputs "MENÜ","+","-","SAVE","CANCEL" usw.) Nun zurück zur Lichtsteuerung. Wenn ich die Alarmüberwachung als weiteren binären Input annehme, ergeben sich 9 Eingangsgrößen, wobei - im Gegensatz zu den Menübuttons - sowohl die 0/1 als auch 1/0 Übergänge relevant sind. Das wären 18 Inputs pro State! (Die State-Machine wird nicht zyklisch, sondern nur bei einer Zustandsänderung bei einer der Eingangsgrößen aufgerufen!) Nun wird es interessant. Beim Neustart des Moduls habe ich state_0 und alle Eingangsgrößen werden erstmalig eingelesen. Jetzt muss ich auf Basis der Eingangsgrößen entscheiden, welcher der erste definierte Zustand nach state_0 ist, da ja noch keine Zustandsänderung erfolgte. Nun frage ich mich, was wären sinnvolle Zustände? Mein Problem ist nicht, wie ich 2^18 mögliche Kombinationen abbilde (wie von Euch richtig angemerkt, ergeben ja nicht alle Kombinationen Sinn). Es geht mir mehr darum, nach welchen Eingangsgrößen ich die Zustände unterscheide und welche Aufsplittung überhaupt sinnvoll ist. Mein jetziger Ansatz wäre, die States nur auf die wichtigsten Eingangsgröße zu beziehen, z.B. die Alarmüberwachung und den Lichtsensor (deswegen die Frage nach einer Hierarchie im meinem ersten Post) und von hier aus auf die anderen Sensoreingänge zu reagieren. state_o: state_alarm_off_day: state_alarm_off_night: state_alarm_on_day: state_alarm_on_night: BTW: Ich muss das Problem der Lichtsteuerung nicht zwingend mit einer State-Machine lösen! Nur wenn ich mit wenigen Zuständen auskäme, wäre das für mich codetechnisch irgendwie symphatischer (da überschaubarer), als mehrfache Abfragen und Verzweigungen in Assembler. Ich hoffe, Ihr könnt nun nachvollziehen, was mein Problem ist :-) Als Nichtinformatiker ist das echt schwer in Worte zu fassen... MFG Andy
Andy W. schrieb: > Mein jetziger Ansatz wäre, die States nur auf die wichtigsten > Eingangsgröße zu beziehen, Du hast absolut nichts verstanden. Du hast garkeine States, du kannst höchstens welche erfinden um die Sache kompliziert zu machen. Aber, nur zum Beispiel, Tag/Nacht ist kein State im Sinn einer State machine, denn da muss kein Zustand gespeichert werden, es ist Tag wenn es hell ist und Nacht wenn es dunkel ist. Da soll wohl die Logik brutal vergewaltigt werden, um ganz einfache Zusammenhänge in ein theoretisches akademisches Konzept zu zwängen. Da musst du dir halt beliebige States ausdenken, die möglichst überhaupt keine Auswirkungen haben, damit nicht auch noch unnötige Fehler eingeführt werden. Wenn dein Ausbilder dich zwingt das so zu machen, dann kannst du natürlich einen State "Nacht" definieren, und der wird gesetzt, wenn der Sensor von Hell auf Dunkel wechselt, und zurückgesetzt, wenn er von Dunkel auf Hell wechselt. Das ist aber meiner Meinung nach verglichen mit der einfachen Tatsache "Nacht = dunkel" nicht nur hirnrissig, sondern auch noch sehr viel unsicherer, denn gemerkte Werte sind weit weniger zuverlässig als der direkte Input - geht der Zustand "Nacht" aus irgendeinem Grund mal verloren, wird der Fehler nach deiner Programmbeschreibung ja erst beim nächsten Wechsel des Eingangs bemerkt und korrigiert, also u.U. erst nach fast 12 Stunden. Ich verabschiede mich hier aus dem Thread, der führt zu nichts. Georg
Theor schrieb: > Nämlich: "Fange am Anfang an". Da gibt es aber zwei! :-) > Ja. Zwei Anfänge. Nun, ohne Dir jetzt direkt widersprechen zu wollen: Ich mache es anders. Aus meiner Erfahrung heraus fange ich immer mittendrin an. Für mich hat sich die Methode bewährt, mir den stationären ("eingeschwungenen") Fall vorzustellen und dort die einzelnen Zustände so wegzuprogrammieren, wie sie mir gerade unterkommen. Anfangszustände, Initialisierung, Fehlerbehandlung, Abdichtung gegen unzulässige Übergänge mache ich immer hinterher.
Andy W. schrieb: > Mein jetziger Ansatz wäre, die States nur auf die > wichtigsten Eingangsgröße zu beziehen, [...] Nein. Begriffliches Chaos. Auch wenn es unkuhl ist: Man DARF sich allgemeinverständlich ausdrücken. Die "state machine" ist eine sinnentstellende Übertragung des englischen "finit state machine", was soviel wie "endlicher Automat" bedeutet. (Das "endlich" bezieht sich auf die Zahl der Zustände; unendliche Automaten sind z.b. die Turing-Maschine oder der Kellerautomat.) Ein "state" ist einfach ein Zustand. So. Jetzt das Hintergrundwissen: Ein endlicher Automat ist durch fünf Dinge vollständig gekennzeichnet: - die Menge X der Eingangssignale, - die Menge Y der Ausgangssignale, - die Menge Z der Zustände, - die Überführungsfunktion, - die Ausgabefunktion. Details, auch zu Moore/Mealy, sind anderswo nachzulesen. Zustände sind (NUR!) dann notwendig, wenn auf IDENTISCHE Kombinationen von Eingangssignalen UNTERSCHIEDLICH reagiert werden muss. Der Zustand "merkt" sich die Vorgeschichte. Jetzt zu Deiner Frage, so wie ich sie verstehe: Ich weiss nicht, ob es eine formal definierte Methodik gibt, die Zustände zu identifizieren. Ich würde mit einer Zuordnungstabelle anfangen, in der ich zu jedem Eingangsvektor den gewünschten Ausgangsvektor aufschreibe. Interessant sind jetzt die Fälle, in denen es zu DEMSELBEN Eingangsvektor mehrere sinnvolle/erwünschte Ausgangsvektoren gibt. Das sind genau die Fälle, wo man "Hilfsvariablen" braucht, um die jeweils richtige Ausgangs- belegung auszuwählen -- und diese Hilfsvariablen sind genau die Zustandsvariablen. Das ist jetzt nur ein Schuss aus der Hüfte; ich habe das so noch nie bewusst gemacht.
Boris O. schrieb: > Einen Ablauf kann ich auch mit einem Programmablaufplan, > einem UML-Sequenzdiagramm oder Pseudo-Code bewerkstelligen, Ja, sicher?! Das sind nur andere Möglichkeiten, denselben Automaten zu definieren (wenn es derselbe Ablauf ist).
@ Andy Ganz offen gesagt, geht es mir ein bisschen wie Georg. Ich kann leider nicht definitiv den Finger auf den wunden Punkt legen. Es gibt eher viele kleine "Halbverständnisse", aus denen Du eine Gesamtheit machen willst, aber es kommt was Krudes dabei heraus. Zunächst einmal hat die State-Machine der Benutzeroberfläche nicht zwingend etwas mit der State-Machine der damit kontrollieren Steuerung zu tun. Im Gegenteil, wird man sich von selbst anbietenden hierarchischen Strukturen auch so modellieren und implementieren, weil das die Übersicht erhöht. Du aber hörst Dich so an, als wolltest Du die State-Machine der Oberfläche mit der der Steuerung irgendwie verheiraten. Ob nun eine State-Machine auf Flanken reagiert oder Zustände ist ein Implementierungsdetail der State-Machine selbst, aber kein notwendig festzulegendes Detail beim Entwurf. Auch spielt es überhaupt keine Rolle für den Entwurf ob der Mechanismus einer State-Machine nur bei Zustandsänderungen aktiv wird oder zyklisch, denn im zweiten Fall, würde sich ohne Änderung der EIngangsgrössen kein neuer Zustand und kein veränderter Output ergeben. Dann sind State-Machines selbst kein Entwurfsmittel, mit dem Fokus auf eine Strukturierung. Es hilft nicht dabei, irgendwelche "wichtigen" Zustände zu finden. Auch werden damit verschiedene Eingangszustände nicht in relevant oder irrelevant unterschieden. Das sind Entscheidungen, die Du treffen musst. Sie ergeben sich nicht aus der Verwendung des Entwurfsmusters. Es sind hier an sich nicht so sehr Begriffe der Informatik die fehlen, meine ich, sondern die Denkweise - die Betrachtung des grundsätzlichen Unterschieds von Kombinatorik und zustandsabhängigen Systemen, wie sie sich gliedern und hierarchisieren lassen. Das kann man zwar erklären, aber zum Verständnis ist unbedingt auch das Üben nötig. Auch das Üben der Implementierung in einer imperativen Sprache. Ich rate Dir ernsthaft, zunächst einmal einfache State-Machines zu entwerfen. Und im Vergleich einmal etwa die State-Machine eines an sich kombinatorischen Problems (etwa ein UND-Gatter) und dazu eine eines inhärent zustandsbehafteten Systems (etwa eine Ampelsteuerung). Ich glaube, wenn ich mehr versuchte zu erklären, würde die Verwirrung nur noch grösser.
@ Andy An einer Stelle will ich aber mal direkt einhaken: Du schreibst: > Es geht mir mehr darum, nach welchen Eingangsgrößen ich die Zustände > unterscheide und welche Aufsplittung überhaupt sinnvoll ist. Es gibt zwei Arten der Abhängigkeit bzw. Unabhängigkeiten: 1. Es gibt manchmal Gruppen von Eingangssignalen deren Zustände sich auf einen bestimmten Teil des Outputs (der Wirkung) nicht auswirken. - Das ist eine einzelne State-Machine. Insgesamt also mindestens zwei davon. 2. Es gibt Gruppen von Eingangssignalen, die, falls ein weiteres Eingangssignal einen bestimmten Zustand hat, sich nicht mehr weiter auf den den Ablauf auswirken. Die Signale bilden keine Bedingung mehr für die Erreichung des letztlich entscheidenden Zustandes. Es gibt aber eine Möglichkeit sich den Anfang noch etwas zu vereinfachen: Die naheliegendste Variante richtet sich nach den Ausgangssignalen! Denn die sind es die in der Aussenwelt tatsächlich etwas bewirken. So. Jetzt bin ich aber auch still. :-)
OK. Noch eines: :-) Ich habe Dir oben geraten: "Ich rate Dir ernsthaft, zunächst einmal einfache State-Machines zu entwerfen. Und im Vergleich einmal etwa die State-Machine eines an sich kombinatorischen Problems (etwa ein UND-Gatter) und dazu eine eines inhärent zustandsbehafteten Systems (etwa eine Ampelsteuerung)." Aber ich möchte das korrigieren. Entwirf zunächst eine Kombinatorik als State-Machine und dann ein einfaches Flip-Flop - und erst später eine Ampelsteuerung.
Hallo zusammen, super, Danke für die konstruktive Kritik, speziell die sachdienlichen Anregungen von Theor und Possetitjel. Da waren ein paar ganz wichtige Infos dabei! Ich wünsche Euch noch einen schönen Abend! MFG Andy
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.