Aktionen

Der Editor einer Aktion: Identität und Ort, der Block des Skripts, was ein Skript lesen und schreiben darf, jede Prüfmeldung, der Befehl Ausführen und sein Journal, wer den letzten Lauf ausgelöst hat, was die Aktion ausführt, Aktivieren und Deaktivieren, Kopieren und Löschen und die Grenzen eines Laufs.

Eine Aktion ist ein Block aus JavaScript-Anweisungen, der den Adressraum liest und Variablen der Art Merker sowie Tags schreibt. Aktionen sind der Schreibweg von Logic: Sie laufen auf Anforderung (Ausführen), über einen Auslöser, aus einer Schaltfläche im Dashboard, die an sie gebunden ist, oder bei Start oder Abschluss eines Laufs aus Process, über einen Befehl mit Logic-Aktion. Wählen Sie eine Aktion unter dem Abschnitt Actions der Spalte von Logic, oder drücken Sie Öffnen in ihrer Zeile in der Tabelle ihres Ordners oder der Wurzel ihres Abschnitts, um ihren Editor zu öffnen (eine mit Neu… > Neue Aktion angelegte Aktion wird nicht geöffnet, sondern in dieser Tabelle markiert, siehe Anlegen und Kopieren); Lesen setzt Logic anzeigen voraus, Bearbeiten Logic konfigurieren, Ausführen Logic bedienen.

Die Kopfzeile zeigt die Marke der Aktion, den Namen, die Zeile "Ein Skript, das Sie auf Anforderung ausführen oder das ein Auslöser für Sie ausführt und dabei Variablen und Tags schreibt." und eine Pille Deaktiviert, solange die Aktion aus ist. Die Spalte des Formulars enthält IDENTITÄT, SKRIPT und Verwendet von; die Schiene enthält LETZTER LAUF.

Identität

Skript

Die Karte SKRIPT ist der Editor für Skripte mit dem Hinweis "JavaScript-Anweisungen (let, if, for, Funktionen). Merker-Variablen schreiben Sie durch Zuweisung (Variables.Setpoint = 21.5;) und Tags mit Connector.Driver.Device.Tag.Write(value). Lesevorgänge werden nicht auf Qualität geprüft: Fragen Sie .State() ab und sichern Sie Lücken mit ?? ab, bevor Sie rechnen." Das Skript speichert bei jedem Tastendruck automatisch und wird jede halbe Sekunde geprüft; die Meldung erscheint unter dem Hinweis. Die Prüfung führt das Skript nie aus.

Ein Skript ist gewöhnliches JavaScript im strengen Modus (lokale Werte, if, Schleifen, Funktionen, Math, Date, JSON) über demselben Adressraum und derselben Lesefläche wie Ausdrücke, mit zwei Unterschieden. Lesevorgänge sind nicht durch die Qualität geschützt: Eine Lücke liest als null, prüfen Sie also .State() und sichern Sie das Rechnen mit ?? ab; einen schlechten Messwert zu behandeln ist genau das, wofür Aktionen da sind. Und ein Skript darf Variablen der Art Ausdruck lesen (ihren veröffentlichten Wert); nur ein Ausdruck darf nicht auf sie verweisen.

Ein Live-Datenpunkt (ein Tag, eine Variable, ein Alarm, ein Kanal von Process) ist der Datenpunkt, nicht sein Wert. Lesen Sie seinen Wert also über ein Element: if (Variables.Start.ValueToBool()), Variables.Level.ValueToReal() > 80, if (Alarms.High.IsActive). Nackt geschrieben in der Bedingung von if, while, do, for oder ?:, als Operand von !, && oder ||, in einem Vergleich oder in der Arithmetik (+= und die anderen zusammengesetzten Zuweisungen eingeschlossen) gälte er immer als wahr oder läse nie seinen Wert: if (Variables.Start) { … } führte seinen Block bei jedem Lauf aus, gleich welchen Wert die Variable hat. Die Prüfung lehnt das ab und nennt das Element, das stattdessen zu lesen ist (Was die Prüfung ablehnt). Ein Datenpunkt, der einer Funktion übergeben wird, und jedes Element eines Datenpunkts bleiben, wie sie geschrieben sind. Dasselbe gilt für ein switch über einen nackten Datenpunkt oder ein case, das einen nennt (lesen Sie .Value), für die linke Seite von ?? (lesen Sie .Value) und für einen Platzhalter ${…} eines Template-Literals (lesen Sie .ValueToString()). Eine zusammengesetzte Zuweisung an eine Variable (Variables.Total += 1, -=, ||= und die übrigen) liest die Variable als den Datenpunkt, bevor sie schreibt, und wird deshalb mit der einfachen Zuweisung abgelehnt, die funktioniert: Variables.Total = Variables.Total.ValueToReal() + 1.

Was eine Aktion schreiben darf

Genau zwei Formen verändern die Anlage, und beide gehen durch den protokollierten Schreibkanal:

Ein Tag trägt zwei Schreibbefehle, und das Skript wählt danach, ob es die Antwort braucht:

Gewartet wird auf der Aktionsspur, ein langsames Gerät hält also allein die Aktionen hinter dieser auf, und der Schreibvorgang wird nie zurückgezogen: Ein Wert, der nicht rechtzeitig bestätigt wird, ist weiter unterwegs, und seine Bestätigung wird protokolliert, wenn er ankommt. Genau das sagt auch die Antwort: "'Cmd' wurde nicht innerhalb von 2000 ms bestätigt; der Wert ist noch zum Gerät unterwegs." Mit weggelassenem oder auf true gesetztem continueOnFailure antwortet der Befehl false, und das Skript läuft weiter; mit false endet der Lauf an dieser Zeile und nennt dabei das Ziel und den Grund.

Kein Schreibvorgang bricht von sich aus ein Skript ab. Ein Schreibvorgang, der abgelehnt wird, bevor etwas gesendet ist, und einer, den die Anlage ablehnt oder nie beantwortet, schlagen beide für sich allein fehl: Der Rest des Skripts läuft, und der Lauf endet als Lauf, der mit fehlgeschlagenen Schreibvorgängen gelungen ist. Zurückgenommen wird auch nichts, was vor einem fehlgeschlagenen Schreibvorgang angewendet wurde, bleibt also angewendet, und das Journal zeigt jeden Schreibvorgang als alten auf neuen Wert unter der Quelle Aktion. Die Gründe, in denen eine Ablehnung zu lesen ist:

• "Das Schreiben auf 'X' wurde abgelehnt: Der Wert ist nicht endlich." (NaN oder unendlich)
• "'Tag' ist im Connector nicht angelegt." (ein deaktiviertes Gerät oder ein Tag, das der Connector nicht trägt)
• "'Wert' konnte für 'Tag' nicht umgewandelt werden." (der Wert passt nicht zu dem Datentyp, den das Tag schreibt)
• "'X' ist von '<holder>' schreibgeschützt." (ein laufendes Rezept oder eine Verriegelung hält die Quelle)
• "'Cmd' wurde nicht geschrieben: das Gerät ist nicht verbunden." (das Gerät gilt bereits als ausgefallen, es wird also nichts für es eingereiht)
• "Das Schreiben auf 'Tag' ist fehlgeschlagen: Der Connector läuft nicht."
• "Die Variable 'X' wurde nicht gefunden." und "'Variables.X' ist eine Ausdrucksvariable: Sie wird berechnet und nie geschrieben."
• Was immer die Anlage oder ihr Treiber geantwortet hat, in ihren eigenen Worten, wenn die Ablehnung von der Leitung kam.

Ein Wert, den ein neuerer Schreibvorgang auf dasselbe Tag in der Warteschlange des Geräts überholt hat, ist kein Fehlschlag: "'Cmd' wurde vor dem Senden durch einen neueren Wert ersetzt." ist genau das, was geschehen ist, der neuere Wert ist der, den die Anlage erfährt, und gemeldet wird das nirgends außer einem WriteAndWait, das false antwortet, weil dieser Wert nicht der ist, der hinausging.

Was einen Lauf sehr wohl beendet: ein Fehler des Skripts selbst (ein Syntaxfehler, eine Adresse, die nichts benennt, eine Ausnahme), ein WriteAndWait(…, false), dessen Schreibvorgang fehlschlug, und die Grenzen des Laufs unter Ausführen.

Welche Fehlschläge der Lauf selbst melden kann, folgt daraus, wer gewartet hat. Ein Write, das abgelehnt wird, bevor etwas gesendet ist, wird abgelehnt, während das Skript noch läuft, der Lauf zählt es also, und das Aktionsprotokoll sagt es; ein Write, das die Anlage danach ablehnt, wird lange nach dem Ende des Laufs beantwortet, es ist also die Konsole von Ereignisse unter dem Namen der Aktion, die es trägt, und nie der Lauf. Ein WriteAndWait ist für die Antwort geblieben, es zählt also, wie die Antwort auch ausfiel.

Was die Prüfung ablehnt

Die drei Meldungen zu WriteAndWait beurteilen, was im Text selbst steht. Ein Argument, das der Editor durch Lesen nicht klären kann (eine Variable, ein berechneter Ausdruck), wird beurteilt, wenn der Aufruf tatsächlich erfolgt, und derselbe Satz beendet dann den Lauf an dieser Zeile.

Lokale Werte in JavaScript (let x = 1; x = x + 1;) bleiben von diesen Regeln unberührt.

Ausführen

Ausführen ist der führende Befehl der Leiste über einer offenen Aktion; er wird nur für eine Rolle mit Logic bedienen gezeichnet und ist mit "Runtime gestoppt" ausgegraut, solange die Station nur lesend ist (die Projektierungssperre graut ihn nicht aus: Ausführen ist Bedienen und nicht Konfigurieren). Hat die Rolle auch Logic konfigurieren, wird zuerst der Entwurf im Editor gespeichert, und der Lauf führt die gespeicherte Definition aus; ohne diese Berechtigung führt der Lauf die dauerhafte Definition aus (die Felder werden nur gelesen, die beiden gehen also nie auseinander).

Jeder Lauf läuft auf der Aktionsspur mit einer frischen Maschine für das Skript, zwischen zwei Läufen dringt also kein Zustand herüber, und nie laufen zwei Skripte zugleich: Sie laufen eines nach dem anderen, in der Reihenfolge, in der sie angefordert wurden. Die Spur ist nicht der Zyklus von 100 ms. Ausdrücke, Alarme, Quittierungen und von anderswo eintreffende Schreibvorgänge laufen weiter, während ein Skript läuft, ein Zyklus kann also mitten in eines fallen, und zwei Lesevorgänge in demselben Skript können verschiedene Durchgänge sehen; dafür verzögert eine Aktion, die auf ein Gerät wartet, allein die hinter ihr eingereihten Aktionen und sonst nichts in der Station.

Ein Lauf wird jenseits von 500 ms ("Das Skript wurde abgebrochen: Es lief über das Zeitlimit von 500 ms hinaus (Endlosschleife?)."), 100.000 Anweisungen oder 4 MB Speicher abgebrochen, jeweils mit einer Meldung, die die Grenze nennt. Die 500 ms messen das laufende Skript: Die Zählung ruht, solange ein WriteAndWait auf ein Gerät wartet, und wird danach wieder aufgenommen, ein korrektes Skript wird also nie für langsame Anlagen verantwortlich gemacht. Eine deaktivierte Aktion schlägt fehl, ohne zu laufen ("Die Aktion ist deaktiviert."); eine gestoppte Runtime antwortet "Die Runtime der Logik läuft nicht."

Das Aktionsprotokoll meldet "Lauf erfolgreich in 12 ms.", wenn jeder Schreibvorgang durchkam, "Lauf erfolgreich in 12 ms, 1 Schreibvorgang fehlgeschlagen: Cmd: 'Cmd' wurde nicht geschrieben: das Gerät ist nicht verbunden.", wenn das Skript selbst zu Ende lief und ein Schreibvorgang nicht (ab dem zweiten Fehlschlag mit "Lauf erfolgreich in 12 ms, 3 Schreibvorgänge fehlgeschlagen, der erste: Cmd: 'Cmd' wurde nicht geschrieben: das Gerät ist nicht verbunden."), oder "Der Lauf ist fehlgeschlagen: <Grund>", wenn der Lauf selbst schlecht endete.

Der fehlgeschlagene Lauf erreicht die Konsole von Ereignisse, unter dem Namen der Aktion und zusammen mit dem, was sie aufgerufen hat: Manuell beim Befehl, Dashboard bei einer Schaltfläche, MCP beim Agenten, der Name des Auslösers bei einem geplanten Lauf und Process · <unit> · <action> bei einem Lauf aus Process. Er wird beim ersten Mal als Warnung protokolliert, zusammengefasst, solange er mit derselben Ursache weiter fehlschlägt, und noch einmal vermerkt, wenn er sich erholt, und diese Zeile der Erholung ist der einzige Eintrag, den ein erfolgreicher Lauf dort je schreibt. Ein abgelehnter Schreibvorgang erreicht die Konsole auf demselben Weg und unter demselben Namen, und aus demselben Grund wird die Aktion benannt und nicht der Lauf: Die Antwort der Anlage kann Sekunden nach dem Ende des Laufs eintreffen, und dann ist kein Lauf mehr da, der fehlschlagen könnte. Ein Lauf, der einfach gelingt, und jeder Wert, den er schreibt, wird allein in die ausführliche Aufzeichnung geschrieben: Ein Skript, das in jedem Zyklus schreibt, erzeugt Werte zu Tausenden, und eine Konsole voll davon ist eine Konsole, in der niemand die Neuigkeiten der Station lesen kann.

Die Schiene LETZTER LAUF zeigt, wann die Aktion zuletzt lief (oder "Noch nie ausgeführt."), "Dauer: N ms", wer sie ausgelöst hat (unten), den letzten Fehler in einem warnenden Hinweis, die fehlgeschlagenen Schreibvorgänge dieses Laufs in einem eigenen warnenden Hinweis (derselbe Satz, den auch das Aktionsprotokoll trug, ein Lauf, der gelang und trotzdem einen Sollwert stehen ließ, sagt es hier also ebenfalls) und die Erinnerung "Läufe werden auf der Aktionsspur ausgeführt, einer nach dem anderen. Nur ein fehlgeschlagener Lauf erreicht die Konsole der Ereignisse; ein erfolgreicher Lauf und jeder Wert, den er schreibt, bleiben für die ausführliche Aufzeichnung erhalten. Auslöser rufen Aktionen nach Zeitplan auf." Die Schiene gehört zur laufenden Aktion: Ein automatisches Speichern leert sie nie; ein Neustart der Runtime tut es.

Ausgelöst von

Unter der Dauer sagt die Zeile "Ausgelöst von: …", was die Aktion zuletzt ausgeführt hat:

Verwendet von

Die Karte Verwendet von listet alles auf der Station, was die Aktion ausführt ("Alles auf der Station, was diese Aktion ausführt."), gelesen, wenn die Aktion geöffnet wird: eine Zeile je Befehl aus Process, der sie auslöst, je daran gebundenem Auslöser und je Schaltfläche im Dashboard, die sie ausführt.

Ohne Einträge sagt sie "Nichts auf der Station führt diese Aktion aus."; wenn die Verweise nicht gelesen werden können, "Diese Aktion ist möglicherweise noch in Verwendung. Versuchen Sie es erneut, bevor Sie sie löschen oder umbenennen." mit Erneut versuchen. Die Karte liest nur, daher sieht jede Rolle sie, auch während die Station im Engineering gesperrt ist. Lesen Sie sie, bevor Sie eine Aktion deaktivieren oder löschen: Ein Befehl aus Process, dessen Aktion verschwunden ist, führt nichts aus und sagt es auf seiner Seite.

Den auslösenden Lauf lesen

Eine Aktion, die ein Lauf aus Process bei Laufabschluss auslöst, liest diesen Lauf unter dem Zweig LastRun der Einheit, der ihn hält, sobald die Aktion läuft; eine bei Laufstart ausgelöste liest die Metadaten des startenden Laufs unter Procedure.Metadata. Punkte aus Process lesen sich als reine Werte, ohne .Value dahinter, anders als Variablen, und ein Punkt, den der Lauf nicht hält, liest sich als null, schützen Sie ihn also ab:

if (Process.Oven_soak.Oven_1.LastRun.Verdict === "Ok") {
  Variables.Last_serial = Process.Oven_soak.Oven_1.LastRun.Metadata.Serial;
}
const peak = Process.Oven_soak.Oven_1.LastRun.Evaluations.Soak_check.Temperature_in_range.MaxValue;
if (peak !== null) {
  Variables.Last_peak = peak;
}

Die Adressen werden vollständig ausgeschrieben, wie jede Adresse eines Skripts: Eine Adresse lässt sich nicht aus einer Variablen zusammensetzen.

Befehle

Der Bereich der Wurzel Actions führt jede Aktion mit ihrem Zustand in der Spalte Wert auf: "Aktiviert · letzter Lauf <wann>", mit "· Fehler", wenn der letzte Lauf fehlschlug, "· Schreiben fehlgeschlagen", wenn er gelang und ein Schreibvorgang von ihm nicht, oder "Deaktiviert".

Was Aktionen nicht tun

Sie erteilen keine Befehle für Läufe von Process, bereiten keinen Ablauf vor und fügen keinen Kommentar zu einem Lauf hinzu (diese Punkte sind nur lesende Werte über Bereitschaft und Vorbereitung); sie quittieren keine Alarme; sie laufen nicht nebeneinander; sie halten zwischen zwei Läufen keinen Zustand und teilen keine Funktionen; und sie werden nicht durch Wertänderungen oder Bedingungen ausgelöst, sondern allein durch Ausführen, durch das Intervall eines Auslösers, durch eine Schaltfläche im Dashboard, durch den Agenten oder durch den Befehl eines Laufs aus Process. Ein Lauf aus Process wartet nie auf die Aktion, die er auslöst, und das Ergebnis der Aktion wird nie in den Lauf geschrieben.