ElabNET Technik Forum

@gbglace Jaein, das ist im Grunde ein Teil davon.

Du hast ne Bedingungstabelle (Eingangswerte und deren Ausprägung), die zu einem bestimmten Ergebnis/Aktion führt (Zustand).
Das aktuelle Ergebnis (Zustand) und eine andere oder dieselbe Bedingungstabelle führen wiederum zu einem Ergebnis.

In der Praxis sind in unserem Fall Ranges natürlich wichtig und es muss auch eine Art "Default" Zustand geben, also ein Zustand der eingenommen wird, wenn keine Bedingungen zutreffen. Und wie Du schon sagtest, ist auch das Thema der Hierarchie zu beachten.

Wie's dann dem Anwender "präsentiert" wird, ist dann auch noch eine spannende Frage (Text basiert, tabellarisch, grafisch,...).

Ich bin ein Freund von State-Machines, weil sich da verschiedene Problemstellungen gut abstrahieren/abbilden lassen.

@MiniMaxV2

Naja grafische Wenn Dann Bäume sind bis zu einer gewissen Komplexität auch noch gut darstellbar. Aber bei vielen Inputwerten und unterschiedlichen Ergebnissen je Kombinatorik ist das dann auch keine Freude mehr. Das dann nur noch gut für Großformatige Ausdrucke zur Präsentation was man sich schlaues ausgedacht hat.

Ich bastel da auf Arbeit viel mit SAS und quäle da unsere Datenbanken. Und wenn ich meine Logiken für Zieldatenfelder in solchen xls gut abbilden kann, dann mache ich das gern im xls. Weil ich kann das dann auch direkt einlesen und als Hash-Objekt gegen den Datenbestand halten. Da habe ich in einem Datendurchlauf direkt mehrere gern auch auf einander aufbauende Zielfelder gebaut. Mit SQL-Werkzeugen tippst Dir da nen Wolf oder brauchst mehrfache update-Statements was viel Zeit wg Daten schreiben /lesen bedeutet.
Hab mir das da quasi mal so angeeignet.

Da der TWS Logikeditor im Aufbau doch ganz anders ist als Die Gira Grafiken oder Node-Red, überlege ich noch wie ich mir da meine Logiken dokumentiere um eben dann auch in der Oberfläche einen schnellen Wiedererkennungseffekt der einzelnen Operationen habe. Bringt ja nichts wenn man sich einen schicken Wenn-dann-Baum malt aber die technische Abarbeitung dann doch irgendwie ganz anders ist. Da hast beim Debugging erstmal damit zu kämpfen wo ist eigentlich der Logikknoten aus der Doku gerade im Code versteckt.

Hi Göran
ich stimme dir zu, Zustandsübergangstabellen sind handlich, wenn man sich daran gewöhnt hat. Aber ich sehe da eher den Endanwender( keine Informatiker wie wir ) - Deine Argumentation mit einem großen Eingabealphabeth stimmt schon: Üblicherweise schreibt man die Kombinationen (ohne Beschreibung) an einen Zustandsübergang. Das wird unübersichtlich. Aber anders rum gefragt - in einem Automaten wirst nicht dutzende Zustände haben. Lässt man die ganzen Zustandserhaltungen weg, definiert diese als Default, werden es weniger Verbindungen. Nun schreibt man an einen Übergang nicht direkt die Kombination, sondern macht dies mit einer kleinen Tabelle die beim Hover auf einen Übergang aufgeht, ist das Zustandsübergangsdiagramm gar nicht mehr so wild. Der Nutzer "zieht" einen neuen Zustand in das Blatt, füllt dessen Ausgabetabelle aus, zieht von einem anderen Zustand auf den neuen, füllt dessen kleine Tabelle und fertig ist ein Übergang. Findest du das unübersichtlich?

Übringens ich spreche nicht von Entsdheidungsbäumen - ich spreche von den Zustandsgraphen aus der Automatentheorie Diese sind kompakter als Wenn-dann-Abfolgen mmn.

musst mir mal nen Beispiel schicken. Wie gesagt bin gelernter Bankkaufmann das "programmieren" war alles lernen am offenen Herzen. Automatentheorie ist da jetzt eher wieder was, was ich erst googeln muss.
deswegen kann ich bei den ganzen Docker Threads derzeit einfach immer nur erstaunt mitlesen. da wimmelt es noch so von Fremdwörtern Und bin dankbar das da wer loslegt und am Ende fertige TWS taugliche Container, bestenfalls mit guter Anleitung, abliefert.

Schau dir mal das folgende Beispiel an:



Die grünen Kreise sind die Zustände. Die Pfeile die Übergänge. Hinter jedem Kreis steht eine Ausgangskombination des Ausgabealphabets (Signale - werden gewöhnlich unter den Strich mit einem "E: NAME" geschrieben oder direkt der Vektor z.B. (A,B,C) für drei Signale). Hinter jedem Übergang eine Kombination des Eingabealphabeths. Jetzt stell dir vor, du klickst auf einen der Pfeile und wählst die Signalwerte aus, die den Pfeil "auslösen" - der Übersichthalber wählst einen Namen. Gleiches machst du um die Aktion zu definieren, die ein Zustand auslößt.
Das ganze ist die grafische Darstellung der Zustandsübergangstabelle.

Ich würde ganz gerne den FR nochmal "nach oben" holen, damit das nicht unter die Räder kommt...

Hi Jochen,

Dragonos2000 hat geschrieben: ↑Mo Jun 17, 2019 2:13 pm Ich würde ganz gerne den FR nochmal "nach oben" holen, damit das nicht unter die Räder kommt...

keine Sorge, der geht nicht unter

Das ist genau der Baustein, den ich immer meiner Frau erklären muss, wenn ich mitten in der Nacht schreiend aufwache

Dann bin ich ja beruhigt

*mal wieder nach oben hol*

Mensch ist ja sehr tief verschwunden @S. Kolbinger