WinCC Objekteigenschaft via VBScript

[Medium]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich versuche gerade einem statischen Text in einem anderen Bild per VBS einen neuen Text zu verpassen. (WinCC 7.2) Folgendes Script dazu:

Sub OnClick(Byval Item)       
 HMIRuntime.Screens("Kopf").ScreenItems("Titeltext").Text = "AT-4033"
End Sub

Das Bild "Kopf.pdl" existiert, und darin befindet sich ein statischer Text mit dem Namen "Titeltext". (Das habe ich 3x genau gelesen um Schreibfehler möglichst auszuschließen.) Wenn ich aber den Button, in dessen OnClick-Handler das steckt in der RT anklicke, spuckt der Debugger dieses hier aus:

---------------------------
PDLRT: HMIScreens
---------------------------
Picture : Anwahl.pdl_Events
Function : Sub Button1_OnClick(Byval Item)      
Line : 2
Error : get_Item:Falscher Parameter.
 
Show Source in Debugger?
Press cancel to suppress any further messages.
---------------------------
Ja   Nein   Abbrechen   
---------------------------

Laut Objektauswahl-Dialog im VB Editor sollte ".Text" eigentlich die richtige Eigenschaft sein, und mit dem Fehlertext kann ich so gar nichts anfangen. (Ich nutze ja nichtmals eine Funktion namens "get_Item"... Mit solchen Fehlermeldungen ist ein Debugger auch wieder nix mehr wert.)

Kann einer von euch erkennen wo hier mein Fehler liegt? Vielen Dank im Voraus!



Edit: Ich habe den Objektpfad mal auseinander gezogen:

Sub OnClick(Byval Item)        
 Dim foo 
 Set foo = HMIRuntime.Screens("Kopf")
 Set foo = foo.ScreenItems("Titeltext")
 Set foo.Text = "Test"
End Sub

Jetzt soll der Fehler in Zeile 3 liegen, das Bild "Kopf.pdl" ist aber definitiv vorhanden. Es wird sogar zu diesem Zeitpunkt auch angezeigt! (Es geht hier um das Zusammenspiel einer Anwahlleiste und einem Kopf-Streifen in einer Visu. Der Titel soll sich je nach Button ändern. Beide Bilder werden über ein drittes, in dem entsprechende Bildfenster angeordnet sind zusammengefügt.)

 

[Medium]

Irgendwann will ich jemandem, der für WinCC verantwortlich ist, mal ganz gehörig eine runter hauen. Gerne auch zwei.

Die Lösung:
In den Tiefen der Siemens-Foren bin ich auf ein relativ ähnliches Problem gestoßen, und dort verborgen als letzte Antwort von 2011 stand, dass man die Eigenschaften von unsichtbaren Fenstern nicht per Script ändern kann (und dass per Script gemachte Änderungen bei Ausblenden auch wieder rückgängig gemacht würden...).
In meinem Fall IST das Bild "Kopf" jedoch sichtbar. Ich gucke ja drauf und hoffe, dass sich da was ändert! Aaaaaaber. Das Bild wird nicht "nackt" angezeigt, sondern in einem Bildfenster! Offenbar schafft es dieses dämliche System nicht, ein Bild als sichtbar zu erkennen, wenn es in einem Bildfenster ist. WTF? Wie soll man darauf kommen!?
Lösbar ist das, in dem man den kompletten Pfad vom untersten Basis-Bild (das mit den Bildfenstern) an durchiteriert. Man landet nachher genau beim selben "Kopf.pdl" wie wenn man es direkt machen würde, aber oh wunder oh staun, auch WinCC ist dann endlich davon überzeugt, dass das Bild auch wirklich da ist.

Geht nicht:

Sub OnClick(Byval Item)       
  HMIRuntime.Screens("Kopf").ScreenItems("Titeltext").Text = "AT-4033"
End Sub

Geht:

Sub OnClick(Byval Item)                 
 Dim foo 
 Set foo = HMIRuntime.Screens("BaseScreen").ScreenItems("KopfBild").Screen.ScreenItems("Titeltext")
 foo.Text = "AT-4033" 
End Sub

(In dem Element "KopfBild" ist "Kopf.pdl" angezeigt.)

Dieses dämliche System müssen doch echt Affen gebaut haben. An jeder Ecke solche völlig unlogischen "Besonderheiten", die erkennen lassen, dass da nicht Entwickelt, sondern irgendwie zusammengeschustert wurde - Hauptsache es kompiliert nachher mindestens ein Mal. Und das dann für zigtausend Euro verkaufen, ist ja klar. Hass. Demnächst Kunden die WinCC vorschreiben gleich woanders hin empfehlen am besten.

Entschuldigt meine Ausbrüche, aber ich verschwende jetzt bald schon zwei Monate an diesem Müll, wofür ich mit unserem eigenen Visu-System maximal 3-4 Tage gebraucht hätte. (Sind 2 Projekte.) Und das hauptsächlich mit Überhaupt-Ans-Laufen-Bekommen und Grundsatzdesign, nichtmals den tatsächlichen Prozessbildern nachher.



Edit: Ja ich weiss. Intern werden die Bilder vermutlich nicht einfach so angezeigt, sondern es werden sehr wahrscheinlich voneinander unabhängige Instanzen gebildet. Aber wenn ich dieses Verhalten in meiner Objektstruktur nicht abbilde (und es komplett in der Doku verschweige), dann MUSS ich es so designen, dass Änderungen am Basisobjekt an die Instanzen durchgereicht werden. Das ist komplett bescheuertes "Klassendesign", und im Editor wird dieses dann auch noch verschleiert. Und mich kostet sowas dann potenziell Tage - hier habe ich mal Glück gehabt Google zufällig mit den richtigen Wörtern auf die Reise geschickt zu haben.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist gar nicht doof von Siemens.

Du könntest das Bild "Kopf.pdl" z.B. in 10 verschiedenen Bildfenstern anzeigen lassen. Dann würden nach deiner Logik ja alle Bildfenster die dieses Bild geladen haben angepasst. Und das ist eben nicht immer sinnvoll, beispielsweise wenn du ein Antriebs-Bedienfenster hast, das in einem Popup-Bildfenster für verschiedene Antriebe aufgerufen wird.

 

[PN/DP]

Dieses dämliche System müssen doch echt Affen gebaut haben.

Komisch nur daß hunderte andere Programmierer mit dem mächtigen Siemens-WinCC-"Müll" klarkommen ...

Vielleicht sollte man Dir mal einen Lehrgang bei Siemens empfehlen? Der dauert auch nicht länger als Deine ahnungslose Rumstocherei und hinterher hättest Du nicht nur scheinbare Erfolge sondern wüßtest sogar was Du tust.

Entschuldige meine Direktheit, aber mit Deinem in Deiner Unwissenheit geborenen Urteil über WinCC tust Du Siemens definitiv Unrecht.

Harald

 

[Medium]

Wenn es nur um diese eine Sache ginge hier, hätte ich sicherlich überreagiert. Aber auch erfahrenere Kollegen fluchen hier mindestens täglich ein Mal - nicht nur über WinCC selbst oder das Scripten. So ein Zorn sammelt sich an, SO kurz ist meine Zündschnur auch wieder nicht.

Da geht's dann um Inkompatibilitäten innerhalb einer Hauptversion, und der Konvertierung zwischen diesen, die auch schon mal Bezeichner mit (angeblich) ungültigen Zeichen ohne Nachfrage oder Warnung ändern (die Bezeichner wurden von Siemens-Leuten angelegt, von denen wir das Projekt übernommen haben!). Das eigentlich schlimme daran: Man glaube nicht, dass diese Namensänderungen an alle Verwendungsstellen durchgereicht wird. (Hier ging es um PCS7.)

Dann alleine schon, dass zwei ähnliche aber doch sehr unterschiedliche Produkte existieren (WinCC, WinCC flexible), was das Googlen extrem aufwändig macht. Man findet entweder haufenweise flex Kram den man manuell filtern muss (oft wird das auch erst nach ein paar Beiträgen klar die man erst lesen muss), oder man schließt "flexible" von der Suche aus - hat dann aber auch alle Threads nicht mehr, in denen jemand nur nachgefragt hat ob flex oder nicht.

Es gibt keine Programmierreferenz zum Scripting. Ich muss mir alles an Eigenschaften über den Objektauswahldialog zusammenklauben, die Codevervollständigung im Editor scheitert dank der String-Referenzierung natürlich auch an den wichtigsten Stellen. Der Debugger gibt Meldungen aus, die Funktionen benennen, die man nicht benutzt hat.

WinCC ist eine elendige Klicker-Orgie. Will ich in einem fertigen Projekt farblich gekennzeichnete Zustandsanzeigen umfärben, darf ich in jeden einzelnen Dynamikdialog separat gehen und klickerdiklackermäßig einen halben Tag darauf verschwenden. (In unserem System ist das ein Wert in der Datenbank - das geht sogar während das gesamte System live beim Kunden läuft und benutzt wird. 5min maximal per Fernwartung.)

Man will, weil man zum Testen nicht exakt dieselbe CPU vorrätig hat, schnell mit einer ähnlichen was aufbauen. CPU austauschen? Ähäh. Mache bitte komplett neues Projekt, und kopiere den gesamten anderen Kladderadatsch da rein, und hoffe, dass noch alle Anbindungen passen.

Es sind einfach unendlich viele kleine und größere Stellen, an denen man sehr gut merkt, dass das gesamte Paket von Siemens sehr lange und durch viele Hände gewachsen ist, und - das soll jetzt kein Angriff sein - dass sehr viel Altherrenweisheit darin steckt. So entwickelt man heutzutage einfach nicht mehr. Ich bin nun mal ein junger Bursche, studierter Informatiker oben drauf. Leider fallen einem viele Dinge dann einfach auf, gerade was "Usability" angeht.
Ganz einfaches Mini-Beispiel, was total unnötig den Arbeitsfluss behindert: Im Graphics Designer einfach mal Ctrl-S. Ich speichere gerne und viel, so jung bin ich auch nicht mehr, da keine bösen Erfahrungen gemacht zu haben. Was macht der Designer? Entfernt meine aktuelle Selektion, und nimmt stattdessen das Bild selbst in den Fokus. Wieso!? Das Problem ist dabei, dass wenn man viele Objekte gleichen Typs hintereinander ändert, man netterweise in den Objekteigenschaften immer in der Kategorie ist, die man beim zuvor selektierten Objekt gleichen Typs benutzt hat. Speichere ich nun zwischen durch, muss ich nicht nur suchen wo ich zuletzt war, sondern mir die Eigenschaften wieder neu raussuchen. Das mag für 2-5 Änderungen komplett egal sein, aber jetzt komme ich mal auf mein Beispiel mit den Farbänderungen zurück... Solche mini-kleinen Ärgerlichkeiten werden sehr schnell ein echtes Hindernis. Schön, dass ihr die Zeit habt für solche Spöksken - mein Kunde gibt mir die nicht, und dann Erklärungsnot. Wegen sowas bin ich sauer, und da hilft mir auch kein lächerlich überteuerter Lehrgang, den ich mir dank meiner aktuellen 12-14h Tage ohnehin zeitlich nicht geben kann, danke sehr.

 

[Medium]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist gar nicht doof von Siemens.

Du könntest das Bild "Kopf.pdl" z.B. in 10 verschiedenen Bildfenstern anzeigen lassen. Dann würden nach deiner Logik ja alle Bildfenster die dieses Bild geladen haben angepasst. Und das ist eben nicht immer sinnvoll, beispielsweise wenn du ein Antriebs-Bedienfenster hast, das in einem Popup-Bildfenster für verschiedene Antriebe aufgerufen wird.

Ja, deswegen ja mein Edit. Im Grunde macht das so Sinn wie es ist. Es ist nur leider nirgends (zumindest habe ich nichts dazu gefunden - ich habe natürlich die Scripting-Doku durchgeschaut) explizit erwähnt. Lustigerweise geht es dann aber wieder doch, wenn das Bild direkt auf unterster Ebene aktiviert wird. Dieser eklatante Unterschied im Handling "eigentlich" ein und der selben Sache sollte man einfach irgendwo groß und rot hinschreiben, und schon ist alles paletti.

Aber wie gesagt: Das war eher ein Tröpfchen, der mich hat überlaufen lassen.

 

[Thomas_v2.1]

WinCC ist eine elendige Klicker-Orgie. Will ich in einem fertigen Projekt farblich gekennzeichnete Zustandsanzeigen umfärben, darf ich in jeden einzelnen Dynamikdialog separat gehen und klickerdiklackermäßig einen halben Tag darauf verschwenden. (In unserem System ist das ein Wert in der Datenbank - das geht sogar während das gesamte System live beim Kunden läuft und benutzt wird. 5min maximal per Fernwartung.)

Für wiederkehrende Objekte gleichen Designs kannst du Faceplates verwenden, die du dann im Bild instanzierst. Willst du dann irgendetwas anpassen, machst du die Änderung im Faceplate und alle Instanzen sind sind automatisch geändert.

Man will, weil man zum Testen nicht exakt dieselbe CPU vorrätig hat, schnell mit einer ähnlichen was aufbauen. CPU austauschen? Ähäh. Mache bitte komplett neues Projekt, und kopiere den gesamten anderen Kladderadatsch da rein, und hoffe, dass noch alle Anbindungen passen.

Verstehe ich nicht. Oder hast du WinCC in Step7 integriert?

Ich fand WinCC auch Anfangs unpraktisch und unnötig kompliziert. Aber wenn man weiß wie es funktioniert, kann man eine Menge damit anstellen da das System sehr flexibel ist.

 

[Medium]

Für wiederkehrende Objekte gleichen Designs kannst du Faceplates verwenden, die du dann im Bild instanzierst. Willst du dann irgendetwas anpassen, machst du die Änderung im Faceplate und alle Instanzen sind sind automatisch geändert.

Da hatte ich in der Vergangenheit auch so einige Nachteile entdeckt, die ich aber heute nicht mehr ganz wiedergeben kann. Ich weiss nur noch, dass deren Verwendung mir damals mehr Probleme gebracht hätte, als sie gelöst haben. (Mein letztes und erstes Projekt mit WinCC ist grob 10 Jahre her, da war ich noch sehr Frischling.) Ich werde mir die FPs aber nochmals genauer begucken, überredet (Insbesondere wird dabei interessant, wie sich das mit Scripten bei denen verhält. Da ich oftmals nicht nur einfache Farbwechsel in einfachen Wertebereichen habe, sondern auch schon mal anhand von Bitmustern ran muss und z.B. bei 3-Wege-Ventilen Sub-Komponenten unterschiedlich färben muss, sind Variablenanbindungen bei mir mind. zur Hälfte über ein Script gemacht.)

Verstehe ich nicht. Oder hast du WinCC in Step7 integriert?

Ja, anders kenne ich es gar nicht muss ich gestehen. Eine Abteilung hier entwickelt das Steuerungsprogramm, und ich bin der HMI Mensch. Sobald die DB Strukturen stehen, schnappe ich mir das STEP7 Projekt und lege mit der Visu los. (WinCC flex, Eigenentwicklung, Insevis und jetzt seit laaaangem mal wieder WinCC, was ich aber nur sehr kurz mal vor knapp 10 Jahren noch zu Beginn vom Studium nebenbei mal in der Hand hatte.)

Ich fand WinCC auch Anfangs unpraktisch und unnötig kompliziert. Aber wenn man weiß wie es funktioniert, kann man eine Menge damit anstellen da das System sehr flexibel ist.

Nicht flexibler als unser System, das im Wesentlichen ein Toolset und Code-Module um Delphi herum ist. Ich kann damit was immer mir gelüstet rein programmieren bzw. modifizieren. Aber ja, WinCC ist verglichen zu den anderen schon sehr mächtig. Aber die oft seltsame und prosa-lastige Doku, mit einer großen Priese Siemens-eigenem Jargon, macht es unglaublich schwer sich da rein zu fressen.
Und mal Hand auf's Herz: Ich habe fast ausschließlich autodidaktisch Pascal/Delphi, C#, Java, HTML, VB und etwas C++ gelernt. Wenn so ein "popeliges Bildchenbauprogramm" Schulungen braucht, dann ist da sicherlich nicht bei MIR etwas falsch gelaufen. (Ohne prollig klingen zu wollen.)

Auch nette Punkte: Warum ist eine mittelgroße Visu - ohne Infrastruktur, nur Projektdateien - auch schon mal satte 2-10GB groß bei WinCC? (Bei uns z.B. 7-10MB + Infrastruktur (welche nur eine MySQL DB ist).) Und alles um Siemens herum läuft oft sehr schneckig, selbst auf richtigen Boliden-PCs mit SSD und allem. Ich fühle mich mit den meisten Tools in meiner Arbeit eher behindert und ausgebremst. Das darf eigentlich bei einem so teuren Produktiv-Werkzeug nicht sein. Meine Schmerzgrenze ist hier wahrscheinlich auch sehr davon geprägt, dass ich oft auch mit "normalen" Desktop-IDEs entwickle, wo die Welt doch sehr anders aussieht. Jemandem der Tag ein Tag aus nur mit Siemens zu tun hat, wird das wohl weder auffallen noch groß stören. Daher kann sich Siemens das vermutlich auch leisten. Der Markt ist sehr klein, und keiner macht wirklich Konkurrenz. Zumal bei vielen Firmen in den Führungsetagen auch das Denken vorherrscht, dass Siemens das non-plus-ultra ist, und auch mit Blick auf Langfristigkeit als einzige Alternative gesehen wird. (Zumindest in Deutschland, zumindest bei größeren SCADA Systemen. Bei Maschinensteuerungen ist es vielen relativ egal.) Da kommt man nicht allzu leicht gegen an.