Was ein Skript ist
Ein Skript ist ein Stück Python, das handelt: Es läuft auf einen Auslöser hin, rechnet, und schreibt, was es entschieden hat. Der Unterschied zu einem Tag ist der Grund, warum es eine eigene Seite hat — ein Tag rechnet einen Wert aus, wenn ihn jemand liest. Ein Skript, das einen Datensatz anlegt oder einen Sollwert setzt, hat keinen Leser und würde deshalb nie laufen.
Pfad statt Name
Abschnitt betitelt „Pfad statt Name“Ein Skript wird unter einem Pfad abgelegt, mit Punkten getrennt, so wie ein Tag:
Plant1.Press.Counter. Alles vor dem letzten Abschnitt wird im Baum links zum Ordner. Der Pfad
ist ein Name, nicht die Identität: Beim Umbenennen bleibt das Skript dasselbe, und ein Ordner
lässt sich mit allem darunter in einem Zug verschieben.
Was auf der Seite steht
Abschnitt betitelt „Was auf der Seite steht“Der Baum links listet alle Skripte. Am Blatt steht, ob eines eingeschaltet ist, ausgeschaltet, oder eine Bibliothek — und, falls Auslöser verlorengegangen sind, deren Zahl.
Die Mitte ist der Code.
Die Eigenschaftsspalte rechts trägt Auslöser, Eingänge und Grenzen. Sie scrollt für sich: Ein Wechsel von Von Hand auf Zyklisch klappt vier Felder auf, und der Code darf davon nicht verrutschen.
Das Dock unten trägt, was das Skript getan hat — siehe Läufe und Probleme.
Was ein Skript liest
Abschnitt betitelt „Was ein Skript liest“Eingänge sind der nachverfolgbare Weg. Sie geben jedem Eingang einen Namen und binden ihn an
ein Tag; im Code steht der Wert dann als inputs["name"]. Weil die Bindung über das Tag geht,
ändert ein Umbenennen des Tags nichts.
Daneben gibt es system.tag.read("Press1.PartCount"). Das ist bequem und der schwächere Weg:
Außerhalb des Codes weiß niemand von dieser Abhängigkeit. Wird das Tag umbenannt, bricht das
Skript und nichts warnt vorher. Der Editor sagt es, sobald system.tag.read() im Code steht.
Alles, was TrakState anbietet, steht unter system. — system. tippen, und der Editor
zeigt den Rest. inputs, params und die Haken bleiben ohne Vorsatz: sie sind der Vertrag des
Skripts, keine Bibliothek. Die vollständige Liste steht unter Die Skript-Schnittstelle.
Was ein Skript schreibt
Abschnitt betitelt „Was ein Skript schreibt“system.tag.write("Line1.Scripts.Threshold", 42) bittet um einen Schreibvorgang. Das Skript
selbst erreicht weder eine Datenbank noch einen Broker; es sammelt seine Schreibwünsche, und die
Instanz führt sie danach aus — mit ihren Rechten, nicht mit denen des Codes.
Genau das macht den Probelauf möglich: derselbe Weg, nur dass am Ende nichts ausgeführt wird.
print() geht in die Ausgabe des Laufs. Sie steht im Protokoll und im Probelauf, denn so
sucht man in einem zwanzigzeiligen Skript nach einem Fehler.
Probelauf und echter Lauf
Abschnitt betitelt „Probelauf und echter Lauf“Zwei Knöpfe, und sie dürfen nie verwechselt werden:
- Probelauf führt das Skript mit den aktuellen Werten aus und schreibt nichts. Was geschrieben würde, steht als Würde schreiben (nichts wurde geschrieben) da.
- Jetzt starten lässt es wirklich laufen. Die Schreibvorgänge werden ausgeführt.
Das Ausführungsprotokoll zeigt ausschließlich Tatsachen — was wirklich geschrieben wurde und ob es die Maschine erreicht hat. Absichten stehen nur beim Probelauf.
Grenzen eines Laufs
Abschnitt betitelt „Grenzen eines Laufs“- Zeit. Ein Lauf wird nach 5 Sekunden abgebrochen, wenn nichts anderes hinterlegt ist. Alles, was das Skript gestartet hat, wird mit beendet – nichts davon überlebt den Lauf.
- Ausgabe. Wer in einer Schleife druckt, füllt keinen Speicher: die Ausgabe ist begrenzt.
- Speicher, Prozesse, Dateien. Unter Linux gilt für einen Lauf als Ganzes – das Skript und alles, was es startet – die Speichergrenze, eine Höchstzahl an Prozessen und eine größte Dateigröße. Unter Windows gibt es dafür kein Gegenstück.
- Höchstens 32 gleichzeitig. Auf einer Installation, die jedem Lauf einen eigenen Benutzer gibt, laufen höchstens 32 Skripte gleichzeitig; ein 33. wird gebeten, es gleich noch einmal zu versuchen.
- Keine Geheimnisse – wo die Installation jedem Lauf einen eigenen Benutzer gibt. Auf einem gehosteten Pool und auf einem dafür eingerichteten Linux-Server läuft ein Skript als eigener Benutzer: Es sieht keine Passwörter oder Schlüssel der Installation, Dateien und Prozess des Servers sind außer Reichweite, und was es in temporären Verzeichnissen hinterlässt, wird nach dem Lauf entfernt. Auf einem Entwicklerrechner (kein eigener Benutzer) läuft ein Skript als Benutzer des Servers und kann dessen Dateien und Umgebung lesen – die Netz-Einstellung gilt weiter, dieser Schutz aber nicht. Die Skripte-Seite sagt es, wenn das so ist.
- Netz. Ein Skript darf sich dorthin verbinden, wohin die Einstellung hinter dem Knopf Skripte: … oben auf dieser Seite es erlaubt – vorbelegt überallhin außer zur Installation selbst. Deren Datenbank, deren übrige Dienste und der Server, auf dem sie läuft, sind nie erreichbar, egal was eingestellt ist. Siehe Netz für Skripte.
Was ein Skript weiterhin kann, ist alles, was sein Mandant über die Instanz darf:
system.tag.write schreibt mit den Rechten der Instanz. Anlegen, Ändern, Ein- und Ausschalten und
Löschen eines Skripts stehen deshalb im Audit-Protokoll, ebenso jede Änderung der Netz-Einstellung.
Objekte aus einem Template
Abschnitt betitelt „Objekte aus einem Template“Ein Template aus dem Store (Einstellungen › Templates) legt Skripte unter einem eigenen
Namensraum an, zum Beispiel OEE.Kennzahlen.Berechnen. Solche Skripte tragen in der Liste die Plakette
„aus
Der Filter Herkunft über der Liste zeigt alle, nur die aus Templates oder nur Ihre eigenen. Ob etwas aus einem Template kommt, entscheidet seine Identität, nicht sein Name: Was Sie im selben Namensraum von Hand anlegen, gehört Ihnen, und ein umbenanntes Template-Objekt behält die Plakette. Löschen und Umbenennen sind erlaubt; ein Update des Templates legt Gelöschtes nicht wieder an.