WinCC Unified Unified sitzungslokale Variablen für Textliste oder Alternativen

RucksackSepp

Level-2
Beiträge
32
Reaktionspunkte
9
Hallo zusammen,

ich steh vor folgendem Problem, mit nur wenigen (nicht schönen) Auswegen. Ich bastelte für unser MTP1200 Basic ein "Pop-Up" zur Ja-Nein-Abfrage, um kritische Bedienhandlungen bestätigen zu müssen. Dafür gibt es zwei Variablen: eine zum Text auswählen über eine Ressourcenliste und eine die als Rückgabewert vom Pop-Up benutzt wird. Bedient wird entweder am Panel selbst, oder auch parallel über den Webzugriff.

Der Rückgabewert ist eine sitzungslokale Variable, da sonst im Falle von zwei Pop-Ups (Panel und Web-Client jeweils verschiedene Abfrage-Gründe, aber gleichzeitig) mit einer Bedienhandlung auch die anderen Abfragen entschieden werden. Soll eben nicht passieren, wäre sicherheitstechnisch nicht unbedingt klug.

Jetzt wird's knifflig. Der Text im Fenster sollte sich nach Bedarf der Abfrage ändern können, wie z.B. "Wert zurücksetzten?". Bisher sind die Sprachen Deutsch und Englisch im Projekt, aber man muss damit rechnen, dass noch eine dritte hinzukommen wird, je nachdem wohin ausgeliefert wird. Man kann den Text z.B. über eine Ressource/Textliste eintragen und über den Pop-Up-Aufruf-Button den Wert dafür bestimmen. Nur der Nachteil dabei ist, dass die Variable zum steuern einer Textliste nur Systemweit sein darf. Damit würde ich aber alle Texte auf allen Clients immer mit dem aktuellen Wert überschreiben, was bei einer Parallel-Bedienung fatal sein kann. Die andere Lösung ist folgende, im Skript des Button die Frage definieren und mit der Sprach-ID einer sitzungslokalen Variable zuweisen. Ist zwar möglich, aber sobald eine dritte Sprache, oder eine Textänderung anfällt, sehr mühselig, bis sehr schwer an alle Buttons zu denken.


TEST = Abfrage-Text
1737008996300.png
YesNoText = Ressourcen-Nummer in der Textliste
1737009129234.png

Kurz zusammengefasst: Sitzungslokal, dann aber in jedem Button, jeden Text inkl. Sprache einpflegen ODER Systemweit, dann aber an allen Clients gleichzeitig der selbe Text, dafür aber komfortabel über eine Textliste.
Gibt es noch eine dritte Möglichkeit an welche ich gerade nicht denke, das Problem zu lösen?
 
Hallo ist dein Popup ein Faceplate/Bildbaustein?
Falls nein, dann würde ich dir raten ein Faceplate für dieses Popup zu erstellen. Dein Vorhaben klingt sehr stark nach einem Typ-Instanz Konzept.
(Dieses Popup kannst du dann auch über die Buttons mit Übergabeparametern konfigurieren und anschließend aufschalten.)
 
Ursprünglich war es ein Faceplate, aber aus vereinzelten Gründen, sowie auch, dass ich nicht grad ein Ass mit JS bin, ist das im Hauptbild. Es liegt auf der Ebene 31 und kann so alles überdecken.
Einer der Gründe ist, dass ich mit einem 20%-Deckkraft-Rechteck alle Bedienungen verhindern kann, außer Ja/Nein. Beim Faceplate hab ich nur den Nachteil, wenn ich es über den Web-Client aufrufe, dass das Faceplate nicht den ganzen "Bildschirm" verdeckt. Beim Text müsste ich trotzdem jeden in jedem Button eintragen.
 
ABER ich kam auf eine Lösung, nicht die sauberste, aber funktioniert.
Eine sitzungslokale Variable mit einem UInt gibt die Sichtbarkeit von Textfeldern vor, welche allesamt in der Ebene 31 liegen, somit wird nur der richtige Text sichtbar und das für jede Sitzung separat.

Nur einen Punkt krieg ich noch nicht zusammen: Wie kann ich die Ebenen-Sichtbarkeit im Hauptbild aus einem Faceplate-Pop-Up einstellen? Bei Buttons im Hauptbild, oder auch wo anders kann ich
Code:
HMIRuntime.UI.SysFct.SetPropertyValue("./Screen", "Layers[31].Visible", 1);
nutzen, oder "./Screen" gegen passendes ersetzen. Aber wie steuer ich das von einem Pop-Up aus?
 
Wie kann ich die Ebenen-Sichtbarkeit im Hauptbild aus einem Faceplate-Pop-Up einstellen?
Ich glaube über reines Skripten funktioniert das nicht.
Aber möglicherweise kannst du versuchen eine Variable im Popup zu setzen, welche direkt mit den Ebenen -> Sichtbarkeit verknüpft ist, dazu musst du aber an die ganzen Ebenen die Variable verknüpfen.
 
Zuletzt bearbeitet:
Ursprünglich war es ein Faceplate, aber aus vereinzelten Gründen, sowie auch, dass ich nicht grad ein Ass mit JS bin, ist das im Hauptbild. Es liegt auf der Ebene 31 und kann so alles überdecken.
Einer der Gründe ist, dass ich mit einem 20%-Deckkraft-Rechteck alle Bedienungen verhindern kann, außer Ja/Nein. Beim Faceplate hab ich nur den Nachteil, wenn ich es über den Web-Client aufrufe, dass das Faceplate nicht den ganzen "Bildschirm" verdeckt. Beim Text müsste ich trotzdem jeden in jedem Button eintragen.
Hierzu mal eben eine kurze Info bzgl. des Verhinderns der Bedienung durch Überdeckung mit einem Rechteck.

Je nachdem welche Image-Version du benutzt ist es möglich durch Bedienung mit zwei Fingern gleichzeitig durch das überdeckende Rechteck hindurch, die dahinterliegenden Elemente zu bedienen. Hatte hierzu einen SR bei Siemens am laufen mit der Aussage, dass dieses Verhalten am Unified Comfort Panel Image 20.0.0.0 behoben werden sollte. Konnte dies aber selbst noch nicht testen.
 
Vielleicht kannst du lokal(Button) die Sprache über ein Übergabewert umschalten und auf drei verschiedene Textlisten(Sprachen) zugreifen?
Dann könnte doch jeder lokal seine Sprache auswählen für diese Buttontexte.
 
Je nachdem welche Image-Version du benutzt ist es möglich durch Bedienung mit zwei Fingern gleichzeitig durch das überdeckende Rechteck hindurch, die dahinterliegenden Elemente zu bedienen. Hatte hierzu einen SR bei Siemens am laufen mit der Aussage, dass dieses Verhalten am Unified Comfort Panel Image 20.0.0.0 behoben werden sollte. Konnte dies aber selbst noch nicht testen.
Kannst du mir das Verhalten genauer beschreiben? Ich entwickle gerade auf 20.0.0.0. Dann kann ich dir bestätigen, ob das Problem behoben ist.
 
Kannst du mir das Verhalten genauer beschreiben? Ich entwickle gerade auf 20.0.0.0. Dann kann ich dir bestätigen, ob das Problem behoben ist.
Überdeckst du Objekte wie z.B. Faceplates oder Buttons mit einem unsichtbaren Rechteckt o.ä., dass du Benutzerabhängig aufrufst um die Bedienung der unterlagerten Objekte zu verhindern, ist es trotzdem noch möglich diese zu bedienen. Tippt man mit zwei anstatt einem Finger auf einen unterlagerten Button (hinter dem Rechteck, also einem Layer tiefer), kann dieser halt immer noch bedient werden.
 
Zurück
Oben