Benutzerdefinierte Logiken (Custom-Logik)
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.
Nutzen Sie den Doc-Mode und den Logik Diagnosemonitor
Custom Logiken wurden ursprünglich von ElabNET dazu genutzt, um Kunden schnell ggfls. spezielle Logiken zur Verfügung zu stellen, ohne dass eine neue Firmware Version ausgerollt werden muss. Auf vielfachen Kundenwunsch, wurde diese Möglichkeit für alle Nutzer freigeschaltet. Dies ist ein Tool “von Experten für Experten”.
Die Nutzung von Custom Logiken ist nicht schwierig, jedoch muss ein Verbindungsliste als json formatiert werden und dies setzt eine gewisse Sorgfalt voraus.
Nutzen Sie den Doc-Modus sowie den Logik Diagnosemonitor (seit IP2 zur V4) für die Prüfung und Beobachtung Ihrer Logik. Überprüfen Sie insbesondere im Diagnosemonitor, ob es zur Abbrüchen, einem Stopp der Logik wegen zu häufiger Aufrufe pro Zeiteinheit und zur Berechnung ungültiger oder nicht darstellbarer Zahlen kommt um unerwünschte Ergebnisse zu vermeiden,
Wer sich bisher noch nicht mit der Schalttechnik auseinander gesetzt hat, dem hilft vielleicht folgende Veranschaulichung mit “Logik-kästchen” (=Modulbaustein) und Verbindungskabel (=Variablen) weiter:
Dieses Bild kann auf die Kodiersyntax übertragen werden:
Innerhalb einer Custom-Logik übernehmen die vordefinierten 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 - 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 https://elabnet.atlassian.net/wiki/spaces/TSKB/pages/398032918 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
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.
Die jeweiligen Modulbausteine sind kompakt und 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