WinCC OPC-XML, Aktualisierung der Daten

usario

Level-1
Beiträge
2
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe Probleme im WinCC bei den OPC-XML-Anbindungen. Folgende Konstellation wird genutzt:
- PC mit WinCC 7.0 SP2 Update 1, Betriebssystem: Windows Server 2003
- PC mit OPC XML-Server, Betriebssystem: Linux, 32 bit

Die Verbindung wird zwar erfolgreich hergestellt (z.B. erkannbar unter Status Verbindungen in WinCC-Explorer oder mittels WinCC Kanaldiagnose), aber die automatische Aktualisierung der EA-Felder in der Runtime-Oberfläche funktioniert nicht bzw. nur sporadisch :sb7: (verschiedene Aktualisierungszeiten bereits ohne Erfolg getestet). Bei anderen "normalen" OPC-Verbindungen funktioniert dies jedoch ohne Probleme. Das Komische ist, dass das Lesen und Schreiben von Daten der OPC-XML-Server mit allen anderen Testclients geht, nur mit WinCC nicht.
Ich habe mir dann mit einem VB-Skript beholfen, das alle Variablen der OPC-XML-Verbindungen zyklisch einliest:

Dim objTag
Set objTag = HMIRuntime.Tags("Variable_XYZ")
HMIRuntime.Trace "Variable_XYZ: " & objTag.Read(1) & vbCrLf

Damit funktioniert zumindest das Einlesen ganz gut, was ja aber eigentlich von WinCC selbst vorgenommen werden müsste??
Wenn ich das Skript nicht starte, bleiben die EA-Felder lange bzw. teilweise sogar immer mit Ausrufezeichen und die Item-Quality auf 0.

Ein weiteres Problem ist das Lesen und Beschreiben mit "GetTagChar" und "SetTagChar" im C-Skript. Sobald ich mit diesen Befehlen auf eine Textvariable zugreife, fallen die EA-Felder erneut kurz aus (und auch weitere EA-Felder der OPC-XML-Verbindungen). Dies tritt jedoch nur bei der ersten Benutzung auf, wenn das Skript dann zyklisch durchläuft funktioniert es.

Ich habe bereits mehrmals den Siemens-Support zu Hilfe gezogen, bisher jedoch leider erfolglos. Hat jemand eine Vermutung woran es liegen könnte?? :idea:
 
Zuletzt bearbeitet:
völlig richtig, das muss auch mit WinCC gehen. Sobald XML-Tags mit E/A Feldern verknüppelt sind (üblicherweise mit 2 sec Aktualisierung), fordert WinCC -wenn die Runtime gestartet wird- diese Werte auch an. Es braucht kein Script im Hintergrund laufen.

WinCC füllt die XML-Tags, die an die EA Felder verdrahtet sind, in eine XML-Subscription und stellt dafür z.B. eine 2 sec Updaterate ein. Nun darf aber ein Server für den aller ersten Schuß dieser Werte eine "schlechte" Quality liefern. Dadurch kann es passieren dass die Werte erstmal "grau" sind und erst beim zweiten Update (nach weiteren 2 sec) mit Quality "good" kommen. WinCC füllt die Tags auch noch nacheinander in die Subscription ein, dadurch verstärkt sich das Problem.

Kannst du prüfen ob der XML-Server beim ersten Schuß (frisch angemeldete Tags) tatsächlich eine "schlechte" Qualität liefert. Wie gesagt das ist nicht "verboten" aber für WinCC "sehr ungünstig".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo und danke für die Antwort.
Ja laut WinCCExplorer bleibt nach dem Start der Runtime die Quality der Items die ganze Zeit "bad" (0) und wird erst nach Starten des von mir erstellten Skriptes oder ohne Skript nach langen Warten (Minuten, Stunden...) "good".
Nutze ich jedoch einen OPC-XML-Testclient, dann liefert der XML-Server direkt nach dem ersten Auslesen "good".
Was kann ich noch probieren?
 
Wie viele XML-Items sind das und in wie vielen WinCC-Bilder oder Taglogging sind diese verdrahtet?

Beim Hochlauf der Runtime verbindet sich WInCC mit dem XML Server, aber erst wenn das Bild, in dem die Variablen verknüppelt sind, in den Vordergrund geschaltet wird, meldet WinCC die Items beim Server zur Beobachtung an. Und zwar einzeln nacheinander! Falls eine Aktualisierungsrate von 2sec eingestellt ist, kommt unter Umständen nach 2sec der erste Wert, nach 4sec der zweite und nach 6sec der dritte, bei 100 Variablen kann das schon eine Weile dauern bis der letzte Wert angekommen ist.

Ich würde mal probieren die XML-Werte im Taglogging einzubinden, das läuft auch mit der Runtime an, bleibt dann aber aktiv (die Variablen bleiben angemeldet). Ist ein ähnlicher Ansatz wie mit einen globalen Script das im Hintergrund läuft, nur verursacht es vermutlich weniger Last.
 
Zurück
Oben