- Beiträge
- 1.120
- Reaktionspunkte
- 571
-> Hier kostenlos registrieren
Hallo zusammen,
da das Thema immer mal wieder aufpoppt & sich auch oft die gleichen Basic-Fragen wiederholen, wollte ich mal einen kleinen Getting-Started Post machen.
Einfach als kleine Sammlung zum Einstieg bzw. versuche ich mich hier an einem RTFM-Post ¯\_(ツ)_/¯
Stand: TIA V21
Zum Anfang: der Sprachkern.
Die Unified-Runtime verwendet ECMAScript V6 & die Google V8 Engine.
Das grundlegende Verständnis der Sprache wird in dem meisten Siemens-Dokumenten oder Hilfen (mehr oder weniger) vorausgesetzt.
Für alle mit SCL-Erfahrung dürfte die Umgewöhnung auf die etwas andere Syntax nicht allzu schwer fallen.
Ich habe mir damals Javascript - Das umfassende Handbuch reingezogen, wobei hier lediglich die erste Hälfte bzw. 2/3 des Buchs für das HMI-Scripting relevant sind.
Danach wird es recht Web-Programmierungs lastig, was nur eingeschränkt für Unified Scripting brauchbar ist.
Ansonsten gibt es mehr als genug Tutorials im Internet, wie beispielsweise auf Mozilla.org.
Das Lernen der Sprache wird euch leider niemand abnehmen ¯\_(ツ)_/¯
All Hail to the AI-Overlord
KI-Unterstützung ist manchmal ganz brauchbar, würde das zum Einstieg aber nicht zur Erstellung von Code empfehlen.
Das Trainingsmaterial der LMMs ist im Normalfall sehr Web-Entwicklungs lastig & macht mit den Siemens-Spezifischen Anpassungen oft Probleme.
Einen Anfänger würden die dabei entstehenden Probleme vermutlich eher verwirren als helfen.
Aber sich Code erklären zu lassen funktioniert für "normalen" Code im gewöhnlich recht gut, hier kommen aber wieder die Unterschiede zwischen der normalen Welt und Siemens zum Tragen (Thema: "Kontext", Möglichkeit zum Integrieren von externen Paketen, usw.).
Generell wichtige Infos
In der Unified-Linksammlung habe ich einiges an Links zu Unified-Scripting zusammengetragen, die ich hier noch nochmal extra verlinken werde.
Das Scripting funktioniert zwar prinzipiell auch einfach hingerotzt, allerdings kann ich die Wichtigkeit des "Programming style guide for JavaScript" nicht genug betohnen.
Speziell die allgemeinen & stylistischen Regeln sind aus meiner Sicht unbedingt einzuhalten, da man ansonsten schnell den Faden verliert ob z.B. etwas im aktuellen Kontext definiert ist oder nicht (=> Verwendung von "let" vs. "var").
Oder ob es sich bei der Variable um eine lokal oder global definierte Variable handelt.
Ein Regeln sind zu Anfang etwas ungewohnt, machen die Arbeit speziell am Anfang einfacher bzw. übersichtlicher.
Eine allgemeine Anleitung zum Scripting findet sich in der Online-Doku, die auch viele der hier beschriebenen Punkte behandelt:
docs.tia.siemens.cloud
Der Code-Editor
Stand V21 fand es irgendjemand bei der Entwicklung von Unified unnötig einen grundlegenden Auto-Formater einzubauen.
Wer braucht schon übersichtlichen Code ¯\_(ツ)_/¯
Und wenn man nicht auf seinen Codestyle achtet, verhakt man sich schnell an den Klammern bzw. darin welche Klamme zu wem gehört.
Für größere Stripts kann man mit dem JS Connector (siehe Linksammlung) in Visual Studio Code arbeiten & eine normale Coding-Umgebung verwenden.
Für kleinere Scrips kann man durchaus auf einen Texteditor oder sonstigen Code-Editor für Javascript zurückgreifen.
Bei mir macht Notepad++ mit dem JSTools-Plugin einen ganz passablen Job.
Eingabehilfen
Es gibt einige Tastenkombinationen, welche im JS-Editor ganz hilfreich sind:
STRG + Leertaste oder STRG + I öffnet die Autovervollständigung.
STRG + J öffnet die kontextbezogene Objektauswahl (HMI-Variablen, Objekte, usw.).
Mehr siehe Online-Doku.
Debugging
Irgendwie ist das häufig das größte Problem, wie ich bisher in diversen Posts zu dem Thema feststellen musste.
Wenn das Script irgendwo auf einen Fehler aufläuft, bricht das Script erst einmal ohne sichtbare Fehlermeldung ab.
Fehler im Code werden von TIA aufgrund der des JIT-Konzepts in Javascript nur sehr zurückhaltend gemeldet bzw. nur, wenn der Code syntaktisch keinen Sinn macht. Tippfehler wie z.B. "tags" anstelle von "Tags" (JS ist Case-sensitiv) werden nicht als Fehler markiert, da etwas namens "tags" durchaus deklariert werden könnte.
Hier kann man also deutlich mehr nicht sofort sichtbare Fehler produzieren, was ein sauberes Arbeiten & mehr Mitdenken zwingend erforderlich macht.
Solange man keinen Browser-basierten Debugger nutzt (Weiteres dazu siehe hier), muss man sich selbst um Diagnosemeldungen kümmern.
Hier kommt der beste Freund der Unified-Scripter zum Einsatz: der TraceViewer
Dieser dient als Konsole für alle möglichen Debugging-Nachrichten.
Weitere Infos zur Verwendung siehe Beitrags-ID 109777593 bzw. der Online-Hilfe.
Als Alternative zu dem BatchScript aus dem Beitrag habe ich hier etwas in PowerShell gestrickt.
Ich persönlich verwende eigentlich immer die Trace zum debuggen, auch wenn der Debugger Haltepunkte und schrittweise Ausführung ermöglicht.
Trace ist generell für alle Nachrichten oder Ausgaben von Infos oder Parametern nutzbar, da sich alles was sich in einen String konvertieren lässt.
So lassen sich auch Daten, Parameter oder Informationen zum Kontext ausgeben.
Für Fehlermeldungen ist Trace im Kontext von try..catch sinnvoll verwendbar.
Grundlegende Infos siehe Exception handling statements der Mozilla-Doku.
Mit "throw" lassen sich übrigens auch eigene Fehlermeldungen schmeißen um den catch-Block auszulösen.
Und auch wichtig/nützlich:
Man bekommt beim Aufschalten des TraceViewers auf z.B. ein Panel alle vorhandenen Einträge übermittelt.
Es ist also auch möglich bereits vergangene Ereignisse nachzuvollziehen, sofern diese noch nicht durch neuere Trace-Einträge verdrängt wurden.
Vermeidet daher nach Möglichkeit zyklische Trace-Einträge.
Die TIA-Hilfe nutzen
Im Abschnit "WinCC Unified Javascript Objektmodell" findet sich eine Beschreibung der Bildobjekte.
Dort finden sich ebenfalls Infos zu den Datentypen der Objekte & Funktionen.
Das ist speziell wichtig wenn man auf Properties von Bildobjekten zugreift oder eine der Objekt-Methoden benötigt.
Wenn man beispielsweise in einem ScreenWindow auf das darin enthaltene Bild zugreifen will (also auf das Bild selbst, um z.B. die Auflösung abzufragen), muss man beispielsweise auf .CurrentScreen (Typ: Object, HmiScreen) zugreifen und nicht auf .Screen (Typ: String, HmiStoredScreen).
Ausführungskontext & Server/Client
Scripte teilen sich innerhalb ihres Kontexts den globalen Deklarationsbereich, sind aber ansonsten separiert voneinander.
Details siehe Online-Doku.
Außerdem handelt es sich bei Unified um einen Server-Client Aufbau, auch wenn es sich dabei um ein einzelnes Panel handelt.
Die Serverseite umfasst beispielsweise den Aufgabenplaner, während die UI rein Client-seitig ist.
Da z.B. per WebClient auch auf einem physischen HMI-Panel mehrere Clients existieren können, kann nicht aus dem Aufgabenplaner auf die UI zugegriffen werden.
Das ist auch der Grund wieso es kein Wertänderungs-Ereignis mehr an den HMI-Variablen gibt.
Für Abfrage auf Wertänderung von HMI-Variablen können beispielsweise Subscriptions oder Trigger von lokalen Scripts an Bildobjekten genutzt werden.
Ausführungsreihenfolge
Benutzerdefinierte Scripte laufen mit niedrigerer Priorität als Systemfunktionen.
Das führt in seltenen Fällen zu Problemen und sollte zumindest im Hinterkopf bedacht werden.
Details siehe Online-Doku.
Synchrone und asynchrone Scripts
Im Prinzip handelt es sich hierbei grob um das Verhalten in welcher Reihenfolge Funktionen bzw. Scripts ausgeführt werden.
Synchrone Scripts werden, wie aus der SPS gewohnt, eines nach dem anderen ausgeführt, während asynchrone Scripts die paralelle Verarbeitung von Funktionen ermöglichen.
Dies kann beispielsweise bei langsamen Funktionen, wie Dateizugriffen, sinnvoll sein.
Für den "alltäglichen Kleinkram" in Unified sind synchrone Scripte für gewöhnlich ausreichend.
Im "Unified Tips für Scripting Dokumentation" gibt es einen Abschnitt zu diesem Thema.
da das Thema immer mal wieder aufpoppt & sich auch oft die gleichen Basic-Fragen wiederholen, wollte ich mal einen kleinen Getting-Started Post machen.
Einfach als kleine Sammlung zum Einstieg bzw. versuche ich mich hier an einem RTFM-Post ¯\_(ツ)_/¯
Stand: TIA V21
Zum Anfang: der Sprachkern.
Die Unified-Runtime verwendet ECMAScript V6 & die Google V8 Engine.
Das grundlegende Verständnis der Sprache wird in dem meisten Siemens-Dokumenten oder Hilfen (mehr oder weniger) vorausgesetzt.
Für alle mit SCL-Erfahrung dürfte die Umgewöhnung auf die etwas andere Syntax nicht allzu schwer fallen.
Ich habe mir damals Javascript - Das umfassende Handbuch reingezogen, wobei hier lediglich die erste Hälfte bzw. 2/3 des Buchs für das HMI-Scripting relevant sind.
Danach wird es recht Web-Programmierungs lastig, was nur eingeschränkt für Unified Scripting brauchbar ist.
Ansonsten gibt es mehr als genug Tutorials im Internet, wie beispielsweise auf Mozilla.org.
Das Lernen der Sprache wird euch leider niemand abnehmen ¯\_(ツ)_/¯
All Hail to the AI-Overlord
KI-Unterstützung ist manchmal ganz brauchbar, würde das zum Einstieg aber nicht zur Erstellung von Code empfehlen.
Das Trainingsmaterial der LMMs ist im Normalfall sehr Web-Entwicklungs lastig & macht mit den Siemens-Spezifischen Anpassungen oft Probleme.
Einen Anfänger würden die dabei entstehenden Probleme vermutlich eher verwirren als helfen.
Aber sich Code erklären zu lassen funktioniert für "normalen" Code im gewöhnlich recht gut, hier kommen aber wieder die Unterschiede zwischen der normalen Welt und Siemens zum Tragen (Thema: "Kontext", Möglichkeit zum Integrieren von externen Paketen, usw.).
Generell wichtige Infos
In der Unified-Linksammlung habe ich einiges an Links zu Unified-Scripting zusammengetragen, die ich hier noch nochmal extra verlinken werde.
Das Scripting funktioniert zwar prinzipiell auch einfach hingerotzt, allerdings kann ich die Wichtigkeit des "Programming style guide for JavaScript" nicht genug betohnen.
Speziell die allgemeinen & stylistischen Regeln sind aus meiner Sicht unbedingt einzuhalten, da man ansonsten schnell den Faden verliert ob z.B. etwas im aktuellen Kontext definiert ist oder nicht (=> Verwendung von "let" vs. "var").
Oder ob es sich bei der Variable um eine lokal oder global definierte Variable handelt.
Ein Regeln sind zu Anfang etwas ungewohnt, machen die Arbeit speziell am Anfang einfacher bzw. übersichtlicher.
Eine allgemeine Anleitung zum Scripting findet sich in der Online-Doku, die auch viele der hier beschriebenen Punkte behandelt:
TIA Portal Information System
Der Code-Editor
Stand V21 fand es irgendjemand bei der Entwicklung von Unified unnötig einen grundlegenden Auto-Formater einzubauen.
Wer braucht schon übersichtlichen Code ¯\_(ツ)_/¯
Und wenn man nicht auf seinen Codestyle achtet, verhakt man sich schnell an den Klammern bzw. darin welche Klamme zu wem gehört.
Für größere Stripts kann man mit dem JS Connector (siehe Linksammlung) in Visual Studio Code arbeiten & eine normale Coding-Umgebung verwenden.
Für kleinere Scrips kann man durchaus auf einen Texteditor oder sonstigen Code-Editor für Javascript zurückgreifen.
Bei mir macht Notepad++ mit dem JSTools-Plugin einen ganz passablen Job.
Eingabehilfen
Es gibt einige Tastenkombinationen, welche im JS-Editor ganz hilfreich sind:
STRG + Leertaste oder STRG + I öffnet die Autovervollständigung.
STRG + J öffnet die kontextbezogene Objektauswahl (HMI-Variablen, Objekte, usw.).
Mehr siehe Online-Doku.
Debugging
Irgendwie ist das häufig das größte Problem, wie ich bisher in diversen Posts zu dem Thema feststellen musste.
Wenn das Script irgendwo auf einen Fehler aufläuft, bricht das Script erst einmal ohne sichtbare Fehlermeldung ab.
Fehler im Code werden von TIA aufgrund der des JIT-Konzepts in Javascript nur sehr zurückhaltend gemeldet bzw. nur, wenn der Code syntaktisch keinen Sinn macht. Tippfehler wie z.B. "tags" anstelle von "Tags" (JS ist Case-sensitiv) werden nicht als Fehler markiert, da etwas namens "tags" durchaus deklariert werden könnte.
Hier kann man also deutlich mehr nicht sofort sichtbare Fehler produzieren, was ein sauberes Arbeiten & mehr Mitdenken zwingend erforderlich macht.
Solange man keinen Browser-basierten Debugger nutzt (Weiteres dazu siehe hier), muss man sich selbst um Diagnosemeldungen kümmern.
Hier kommt der beste Freund der Unified-Scripter zum Einsatz: der TraceViewer
Dieser dient als Konsole für alle möglichen Debugging-Nachrichten.
Weitere Infos zur Verwendung siehe Beitrags-ID 109777593 bzw. der Online-Hilfe.
Als Alternative zu dem BatchScript aus dem Beitrag habe ich hier etwas in PowerShell gestrickt.
Ich persönlich verwende eigentlich immer die Trace zum debuggen, auch wenn der Debugger Haltepunkte und schrittweise Ausführung ermöglicht.
Trace ist generell für alle Nachrichten oder Ausgaben von Infos oder Parametern nutzbar, da sich alles was sich in einen String konvertieren lässt.
So lassen sich auch Daten, Parameter oder Informationen zum Kontext ausgeben.
Für Fehlermeldungen ist Trace im Kontext von try..catch sinnvoll verwendbar.
Grundlegende Infos siehe Exception handling statements der Mozilla-Doku.
Mit "throw" lassen sich übrigens auch eigene Fehlermeldungen schmeißen um den catch-Block auszulösen.
Und auch wichtig/nützlich:
Man bekommt beim Aufschalten des TraceViewers auf z.B. ein Panel alle vorhandenen Einträge übermittelt.
Es ist also auch möglich bereits vergangene Ereignisse nachzuvollziehen, sofern diese noch nicht durch neuere Trace-Einträge verdrängt wurden.
Vermeidet daher nach Möglichkeit zyklische Trace-Einträge.
Die TIA-Hilfe nutzen
Im Abschnit "WinCC Unified Javascript Objektmodell" findet sich eine Beschreibung der Bildobjekte.
Dort finden sich ebenfalls Infos zu den Datentypen der Objekte & Funktionen.
Das ist speziell wichtig wenn man auf Properties von Bildobjekten zugreift oder eine der Objekt-Methoden benötigt.
Wenn man beispielsweise in einem ScreenWindow auf das darin enthaltene Bild zugreifen will (also auf das Bild selbst, um z.B. die Auflösung abzufragen), muss man beispielsweise auf .CurrentScreen (Typ: Object, HmiScreen) zugreifen und nicht auf .Screen (Typ: String, HmiStoredScreen).
Ausführungskontext & Server/Client
Scripte teilen sich innerhalb ihres Kontexts den globalen Deklarationsbereich, sind aber ansonsten separiert voneinander.
Details siehe Online-Doku.
Außerdem handelt es sich bei Unified um einen Server-Client Aufbau, auch wenn es sich dabei um ein einzelnes Panel handelt.
Die Serverseite umfasst beispielsweise den Aufgabenplaner, während die UI rein Client-seitig ist.
Da z.B. per WebClient auch auf einem physischen HMI-Panel mehrere Clients existieren können, kann nicht aus dem Aufgabenplaner auf die UI zugegriffen werden.
Das ist auch der Grund wieso es kein Wertänderungs-Ereignis mehr an den HMI-Variablen gibt.
Für Abfrage auf Wertänderung von HMI-Variablen können beispielsweise Subscriptions oder Trigger von lokalen Scripts an Bildobjekten genutzt werden.
Ausführungsreihenfolge
Benutzerdefinierte Scripte laufen mit niedrigerer Priorität als Systemfunktionen.
Das führt in seltenen Fällen zu Problemen und sollte zumindest im Hinterkopf bedacht werden.
Details siehe Online-Doku.
Synchrone und asynchrone Scripts
Im Prinzip handelt es sich hierbei grob um das Verhalten in welcher Reihenfolge Funktionen bzw. Scripts ausgeführt werden.
Synchrone Scripts werden, wie aus der SPS gewohnt, eines nach dem anderen ausgeführt, während asynchrone Scripts die paralelle Verarbeitung von Funktionen ermöglichen.
Dies kann beispielsweise bei langsamen Funktionen, wie Dateizugriffen, sinnvoll sein.
Für den "alltäglichen Kleinkram" in Unified sind synchrone Scripte für gewöhnlich ausreichend.
Im "Unified Tips für Scripting Dokumentation" gibt es einen Abschnitt zu diesem Thema.
Zuletzt bearbeitet:
