WinCC Unified Unified PC Runtime V20 führt Systemfunktion nicht aus

[Monstablokaz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich nutze Unified PC Runtime V20 Update 4 und habe ein komisches Phänomen. Ich habe 10 Bilder. In jedem Bild ist ein "WEITER" Button. Wird dieser gedrückt soll folgendes passieren:

SetzeBitInVariable()
WechselBild()

-> Mit SetzteBit wird eine Schrittkette gestartet und auf dem nächsten Screen ist der WEITER Button solange nicht Bedienbar, bis die Schrittkette wieder Idle ist. Dazu blinkt noch ein Feld für den aktiven Vorgang und der aktuelle Schritt der Schrittkette wird noch als Text dargestellt. Mehr passiert auf dem Screen in dem Moment nicht.

Also eigentlich super einfache Sachen.

-> in 95% der Fälle klappt das auch wunderbar, aber es kommt zwischendurch zu der Situation, dass SetzeBitInVariable() nicht getriggert wird, aber WechselBild() schon. Das heißt das Drücken Event wird ausgewertet, sonst würde das HMI den Bildwechsel nicht machen, aber das Bit wird in der SPS nicht gesetzt. Ich habe auch schon per Trace kontrolliert, ob es gesetzt und gleich wieder zurückgesetzt wird. Alles nicht der Fall.

Hat jemand eine Idee was das sein könnte oder wie ich herausfinden kann wieso das passiert?

 

[blimaa]

Hi
Ist die Reihenfolge wie du sie hier geschrieben hast? Zuerst Bit und dann Bild wechseln?
Wie wird denn das Bit im Normalfall zurück gesetzt?
Die Kommunikation HMI-SPS ist azyklisch, das heisst das Bit wird nicht wie die SPS Eingänge beim Zyklusstart in das Prozessabbild geschriben, sondern halt dann wenn sie gerade geschrieben werden. Sprich, wenn du dein Bit in einem laufenden Zyklus schreibst, aber direkt danach zurücksetzt, dann bekommt das der Trace unter umständen gar nicht mit, da dieser nur einmal beim Start vom Zyklus aufzeichnet (Standardeinstellung), also bei jedem Start vom Zyklus, aber nichts dazwischen.

Gruss blimaa

 

[Monstablokaz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Reihenfolge ist SetzeBit() und dann WechselBild()

Ich kann das Bit auch nur setzen wenn die Schrittkette Idle ist, ansonsten ist der Button auch nicht bedienbar. Dann setzt das HMI das Bit und die Schrittkette soll losrennen. Am Ende der Schrittkette oder wenn zwischendurch ein Fehler auftritt, wird das Bit durch die SPS zurückgesetzt.

Eine Überlegung ist ein Script, welches das Bild wechselt wenn der Befehl ausgeführt wurde und die Schrittkette <> Idle ist. Dafür hätte ich das Textfeld, wo der aktuelle step angezeigt wird. Auf diese Dynamisierung könnte ich noch ein

if (befehl && step <> Idle)
ChangeScreen

setzen.

Aber eigentlich wöllte ich lieber verstehen, warum das passiert was da passiert^^

 

[Botimperator]

Bezieht sich das "Wechsle Bild" zufällig auf das eigene Bildfenster?
Mit welchem Write-Type wird das SetzeBit aufgerufen?

Wenn das Bild abgebaut wird, wird auch dessen Scriptkontext gekillt.
Wenn du per NoWait schreibst, kann es vorkommen, dass der Schreibbefehl noch läuft während der Bildwechsel angestoßen wird.
Mit ein paar passenden Trace-Aufrufen sollte das aber eigentlich auffallen.
Und es erscheint auch eine, wenn auch etwas kryptische, Meldung im Trace Viewer, wenn ein beschäftigter Scriptkontext beendet wird.

 

[faust]

Guten Morgen.

Ich habe bis jetzt nicht mit Unified gearbeitet (Und das wird auch so bleiben), aber bei WinCC Comfort/Advanced ist es ja so, dass Systemfunktionen, die z.B. an ein Schaltflächenereignis projektiert werden, quasi gleichzeitig angestoßen werden und nicht auf (interne) Fertigmeldungen gewartet wird.

Wie ist denn die von dir genannte Variable projektiert? Aktualisierung "Zyklisch in Betrieb" oder "Zyklisch fortlaufend"?
Nicht, dass bei ersterem der Bildwechsel eine Aktualisierung sporadisch verhindert, weil die Runtime den Aktualisierungsmodus in Verbindung mit der Variablennutzung im Bild nicht rechtzeitig "erkannt" hat.

Vielleicht Blödsinn, den ich erzähle, habe wie gesagt noch nicht mit Unified gearbeitet. Aber ich sehe immer zu, dass ich die Abarbeitung von "Befehlsketten" selbst in der Hand habe (sprich: Script).

 

[Monstablokaz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, es wird das aktuelle Bildfenster gewechselt. Mit den Systemfunktionen schreibe ich die Befehle. Gibt es eine Funktion für "Wait" oder meinst du über ein AckBit aus der SPS?

 

[Botimperator]

Anhang anzeigen 92913

Ja, es wird das aktuelle Bildfenster gewechselt. Mit den Systemfunktionen schreibe ich die Befehle. Gibt es eine Funktion für "Wait" oder meinst du über ein AckBit aus der SPS?

Also ist es so wie ich es mir schon dachte

Als aller erstes das IMMER gültige Gesetz wenn deine Scripte komisches Zeug machen:
Wenn so etwas Probleme macht, wandle es in ein Javascript um & packe den Code in ein try...catch + Trace zur Fehlerausgabe.
Die System-Traces sind mit Fehlerinformationen zu Fehlern in Runtime-Scripts sehr sparsam & meist auch sehr kryptisch.
Das hier bezieht sich zwar auf einen anderen Code, zum Spickeln was man mit Trace() machen kann sollte es aber ausreichen.

SetBitInTag() ist, soweit ich das sehe, eine asynchrone Funktion, hält also den Ablauf deiner Scriptfunktionen nicht auf bis es fertig ist.
Daher wird wohl das gelegentliche Nicht-Ausführen der Funktion kommen, wenn ChangeScreen() mit dem Bildabbau & damit einhergehendem Kontext-Kill schneller ist.

Wenn du betreffend der Ausführungsreihenfolge sicher gehen willst, kannst du entweder per Tag.Write() & hmiWriteWait als Writetype-Parameter arbeiten oder mittels des Promise von Tag.SetBit().
Beschreibung Promise siehe hier, beschreibung der Scriptfunktionen siehe F1-Hilfe.
Evtl funktioniert auch await als präfix für SetBitInTag(). Müsstest du allerdings ausprobieren, Siemens ist manchmal etwas komisch wenn es um das Systemverhalten der eigenen JS-Funktionen geht.
In der F1-Hilfe ist kein Rückgabewert für die Funktion angegeben, also wird es höchstwahrscheinlich nicht gehen.

 

[Monstablokaz]

Ich dachte immer die Systemfunktionen werden synchron abgearbeitet. Das Problem ist dann wohl eher "ich dachte".

Ich probiere es mal mit:

let befehl = Tags("DB_Daten_Befehle_xxx");
befehl.Write(1, hmiWriteWait);

HMIRuntime.UI.SysFct.ChangeScreen("", ".");


Mal sehen ob das besser wird.

 

[Botimperator]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal sehen ob das besser wird.

try {
    let befehl = Tags("DB_Daten_Befehle_xxx");
    befehl.Write(1, Tags.Enums.hmiWriteType.hmiWriteWait);

    HMIRuntime.UI.SysFct.ChangeScreen("Name des neuen Bilds", ".");
} catch (ex) {
    HMIRuntime.Trace("\nAllgemeiner Fehler im Bildwechsel-Befehl.\n" +
        "Bildobjekt: " + item.Name + "\n" +
        "Bild: " + Screen.Name + "\n" +
        "Bildpfad: " + Screen.Parent.Path + "\n" +
        "Fehler: " + ex, HMIRuntime.Trace.Enums.hmiSeverity.Error);
}

 

[Monstablokaz]

Das ist die vollständige Variante ja

Aber wann kommt er in den catch? Versucht er den Befehl so lange zu schreiben wie es geht oder hat er ein Timeout?

 

[Botimperator]

try..catch gehört zum Sprachkern von Javascript.
Dabei handelt es sich um ein Statement zum Abfangen/Behandeln von Fehlern.

Er versucht den Code in try{} auszuführen & erst wenn es innerhalb von try{} zu einem Fehler kommen sollte (also wenn irgendeine Funktion eine exception wirft) landet er im catch{}-Teil.
Läuft der Code innerhalb von try{} ohne Fehler durch, wird der catch{}-Teil nicht ausgeführt.
Du kannst das noch mit einem finally{} erweitern, welcher immer nachfolgend ausgeführt wird.

Siemens setzt Kentnisse über den Sprachkern von Javascript einfach vorraus & erklärt diese nicht extra in der Hilfe.
Komplette Beschreibung von try..catch siehe hier.
Grundsätzlich funktioniert alles im Umfang von normalem Javascript / ECMAScript 6 auch in Unified.

 

[Monstablokaz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja try catch finally ist klar Komme eher aus C#, aber dort ist es ja genauso.

Ich frag mich nur, wann in dieser Konstellation ein catch ausgelöst werden kann. Wenn der Befehl nie gesetzt wird. Ohne das try catch wird wohl, falls der Befehl nicht erfolgreich geschrieben wurde trotzdem mein Bild gewechselt.

 

[Monstablokaz]

Also es funktioniert besser, aber trotzdem habe ich ab und an mal Aussetzer. Im TraceViewer wird kein Fehler aus dem try catch geschmissen.

 

[faust]

Wie ist denn die von dir genannte Variable projektiert? Aktualisierung "Zyklisch in Betrieb" oder "Zyklisch fortlaufend"?

Ich präzisiere meine Frage:
Welche Aktualisierungszeit ist denn projektiert, und welche Verbindungsart (S7-1200/1500, OPC-UA, ...)?

@Botimperator hat jetzt ja fast alles erläutert, was es auf HMI-Seite zu erklären gibt, jetzt kann es meiner Meinung nach "nur" noch an der Behandlung in der HmiPlc-Schnittstelle und/oder dem SPS-Programm liegen.

 

[Monstablokaz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja das war wirklich sehr ausführlich und hat mir auch echt geholfen.

Welche Aktualisierungszeit meinst du genau?

 

[faust]

Aus einer meiner HMI-Variablentabellen als Beispiel:

 

[Monstablokaz]

Ich hatte die Befehle erst auf Anforderung jetzt Zyklisch im Betrieb T2s...

 

[faust]

Zuviel Werbung?
-> Hier kostenlos registrieren

AHA.

"Auf Anforderung" heißt (salopp gesagt), dass die Aktualisierung erst stattfindet, wenn die Runtime eine akute Verwendung der Variable erkennt.
Erst dann wird der ganze interne Prozess zur Werterneuerung in Gang gesetzt.

Wie sich das genau in WinCC Unified äußert kann ich nicht sagen, aber bei WinCC Comfort/Advanced wurde -soweit ich mich erinnere(*)- explizit auf undefiniertes Variablenverhalten bei Verwendung der Konstellation "Variable (Auf Anforderung) in einem Skript" hingewiesen.

(*)
"Soweit ich mich erinnere" deshalb, weil ich diese Art der Variablenaktualisierung nie in zeitkritischem Kontext eingesetzt habe.

 

[Monstablokaz]

Ok, aber ich habe es ja jetzt auf 2s gestellt und naja noch nicht der 100% Erfolg.

 

[faust]

Aber immer noch "Zyklisch in Betrieb", d.h. die Variable wird nur dann aktualisiert, wenn sie im Bild direkt an einem Control projektiert ist.
Und da du einen Bild-Abbau und danach Bild-Aufbau hast, könnte genau dann das von @Botimperator beschriebene Verhalten (in Post #7) zutreffen.