Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 13 Nächste Version anzeigen »

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.

Dieses Bild kann auf die Kodiersyntax übertragen werden:
Innerhalb einer Custom-Logik übernehmen die vordefinierten Logikbausteine 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]
  ]
}

Im Logikeditor wird diese Logik wie folgt dargestellt (wobei in dieser Abbildung als zusätzliche Option der Doktormodus eingeschaltet ist):

Vorteile des Schaltmodul-Konzepts

  • 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.

  • 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 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)

  • Keine Stichwörter