Struktur diese Kapitels

Inhalt dieser Seite

Einführung in das Baukasten-Denken

Die Custom-Logiken ermöglichen es dem Anwender, eigene - auch sehr komplexe - Logikaufgaben zu bewältigen. Die dafür benötigte Kodiersyntax ist an die Schalt- oder Digitaltechnik angelehnt. Sie basiert auf einzelnen Modulbausteinen.

Wer sich bisher noch nicht mit der Schalttechnik auseinander gesetzt hat, dem hilft vielleicht folgende Veranschaulichung weiter:

...

[Intern: PowerPoint-Datei, in der die Grafiken erstellt wurden

]

Man stelle sich einen Logikbaukasten vor, der aus verschiedenen kleinen Kästchen und der nötigen Anzahl von von Kabeln besteht. Jedes dieser Logik-Kästchen hat eine spezifische Funktion (bspw. Logisch-AND) sowie die nötige Anzahl Ein- und Ausgangssteckdosen, in welche die Kabel eingesteckt werden können. Der Anwender kann nun die gewünschten Logik-Kästchen mit Kabeln miteinander in der richtigen Reihenfolge verbinden und erhält so eine Gesamtlogik, welche die gewünschte Funktion abbildet. mit “Logik-kästchen” (=Modulbaustein) und Verbindungskabel (=Variablen) weiter:

...

Dieses Bild kann auf die Kodiersyntax übertragen werden:
Innerhalb einer Custom-Logik übernehmen die vordefinierten Logikbausteine Modulbausteine die Funktion der Logik-Kästchen; sie haben je eine vorgegebene Anzahl von Ein- und Ausgängen und eine interne Funktion.
Als Kabelverbindungen dienen in der Custom-Logik die Variablen.

Als Custom-Logik kann die gleiche Schaltung wie folgt abgebildet werden, wobei hier - anders als im obigen Beispiel mit dem Modulbaukasten - auch die Ein- und Ausgänge der Gesamtlogik verdrahtet sind

...

Dies führt zu folgendem Code (der hier didaktisch dargestellt wird, d.h. in der Praxis könnte er etwas verkürzt werden). Der Aufbau des Codes wird unter Die Struktur einer Custom-Logik erläutert.

{
  "Input": [
    ["Eingang 1 (Gruppe 1)","Status Eingang 1","$In1","a" ],
    ["Eingang 2 (Gruppe 1)","Status Eingang 2","$In2","a" ],
    ["Eingang 3 (Gruppe 2)","Status Eingang 3","$In3","a" ],
    ["Eingang 4 (Gruppe 2)","Status Eingang 4","$In4","a" ]
  ],
  "Output": [
    ["Ausgang","Eine der beiden Gruppen ist TRUE","$Out","a" ]
  ],
  "Module": [
        ["And",["$In1","$In2"],"$Gruppe1"],      
        ["And",["$In3","$In4"],"$Gruppe2"],      
        ["Or",["$Gruppe1","$Gruppe2"],"$Out"]    
  ],
  "Level": [
    ["$In1","bool",false],
    ["$In2","bool",false],
    ["$In3","bool",false],
    ["$In4","bool",false],
    ["$Gruppe1","bool",false],
    ["$Gruppe2","bool",false],
    ["$Out","bool",false]
  ]
}

...

Vorteile des Schaltmodul-Konzepts

...

• Die Logikengine wird durch dieses Konzept sehr schnell. Der Code ist kompakt, da intern alles auf wenigen Grundschaltungen basiert, die jeweils nur wenige Codezeilen umfassen. Das passt dann auch in die Caches der Prozessoren, was die Ausführungsgeschwindigkeit erheblich beschleunigt. Das kann man sich so vorstellen wie der Aufbau von Microprozessoren. Diese basieren im Kern auf einfachen Logik-Gattern, einem Takt und ggfls. Zeitgliedern.

• Die jeweiligen Module Modulbausteine sind nicht nur klein und kompakt , sondern eben auch übersichtlich und damit sehr schnell fehlerfrei zu bekommen.

Ab hier Steinbruch (, d.h. blosse Grundlage für die weitere redaktionelle Bearbeitung)

• Grundlagen: https://forum.timberwolf.io/app.php/kb/viewarticle?a=84

• Auflistung aller verfügbaren Module und Kopiervorlage für einen Custom-Logikbaustein: https://forum.timberwolf.io/app.php/kb/viewarticle?a=115und gut getestet/fehlerfrei.

• Das Schaltmodul-Konzept ermöglicht den Doktormodus mit alle den vielen Fähigkeiten der Diagnose und des Eingriffes, die dieser bietet. Mit prozeduralen Sprachen wäre dies kaum realisierbar.

Struktur diese Kapitels