TIA WinCC RT Prof: Bildaufbau/Datenaufruf dauert ewig lang

Spoonman

Level-1
Beiträge
86
Reaktionspunkte
7
Zuviel Werbung?
-> Hier kostenlos registrieren
Software: WinCC RT Prof. V17 (Server-Client)

Hallo alle zusammen.

Ich habe folgendes Problem. Wenn ich an unserem SCADA System einen Bildwechsel vollziehe, beträgt bei manchen Bildern die Aufbauzeit bis zu 10s. Genauso verhält es sich bei Faceplates, bei denen ca. 40 Variablen geladen werden. Die Script-Diagnose (apdiag) sagt mir, dass alles in Ordnung ist.
Egal wo ich die Bilder aufrufe (Runtime-Client / Webnavigator / Graphics Runtime auf dem Server), es dauert überall gleich lang.
Die Zyklen sind eingestellt auf 2s.

Kann es sein, dass die SPSen für das Auslesen der Daten so lange brauchen? Dieses Problem habe ich bei einer 1516 und ebenfalls bei einer 319er CPU.

Hat jemand ne Idee woran das liegen könnte?

Vielen Dank für eure Hilfe.

Gruß Ralf
 
Hi,

ich denke nicht, dass die SPS-Kommunikation hier so lange braucht. Die Runtime baut ja teilweise das Bild erst auf und verknüpft dann erst die Variablen. Manchmal sieht man das ja, wenn nach einem Bildwechsel noch kurz die ### in EA-Feldern angezeigt werden.
In der Kanaldiagnose würde man ja auch sehen, ob die SPS-Kommunikation nicht mehr hinterherkommt.

War das schon immer so oder erst ab einem gewissen Punkt? Ist es mit der Zeit immer langsamer geworden?
Wie ist die Hardware-Ausstattung der Server?

Leistungsgrenzen eingehalten, die im Handbuch stehen?

Sind viele Dynamisierungen vorhanden? C-Skripte? VB-Skripte? Mit dem Aktionsdialog im TIA-Portal?
Kommunikations-, Skript- und Archivlast wird auch immer in den entsprechenden Systemvariablen angezeigt, die WinCC Professional seit der V17(?) aus V7.5 geerbt hat. Sie heißen alle "@PRF..."
Hier ist es im Anwendungsbeispiel für V7.5 beschrieben, in WinCC Professional sind die Variablen analog.

Aktuelle Updates für V17 auf Server, Client und ES installiert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi LucasMucas,

vielen Dank für deine Antwort. Jedes Objekt ist dynamisiert. Selbst der Variablenname wird mittels VB-Skript zusammen gesetzt.
Bei den Servern handelt es sich um Siemens IPC. Die Leistungsgrenzen haben wir eingehalten und alles ist auf den neusten Stand.
Aus dem vorherigen WinCC haben wir keine Skripte geerbt.
Kommunikations-, Skript- und Archivlast wird auch immer in den entsprechenden Systemvariablen angezeigt, die WinCC Professional seit der V17(?) aus V7.5 geerbt hat. Sie heißen alle "@PRF..."
Das kannte ich bislang noch nicht. Dem werde ich nachgehen.

Vielen Dank
 
Hi,
ich habe Schreib- und Lesegeschwindigkeiten der Problemsteuerungen mit der WinCC Channel Diagnose angeguckt. Folgendes ist mir dabei aufgefallen:
SPS mit langer Aufbauzeit
CPU: 1516-3
SPS mit langer Aufbauzeit
CPU: 319-3
SPS mit normaler Aufbauzeit
CPU: 1516-3
kat2.PNGkat3.PNGklaer.PNG
Die Steuerungen, aus denen die Daten für die langsam-aufbauenden geladen werden, haben sehr hohe Lesezeiten.
Gibt es irgendeine Möglichkeit Einfluss auf diese Zeit zu nehmen? Die Steuerungen mit hohen Lesezeiten haben sehr viel Programm und viele Bausteine zum Abarbeiten. Auf der linken 1500er sind über 500 Bausteine.

Könnte vielleicht eine neuere CPU (Typ 1516 FW3.0) Abhilfe schaffen? Die haben einen 2-Kern Prozessor bei denen 1 Kern für das Anwenderprogramm und der 2. Kern für die Kommunikation zuständig ist.

Gruß Ralf
 
vielleicht hilft Dir das hier bissl weiter:

https://www.sps-forum.de/threads/wincc-v7-5-sp1-mengengerüst-für-s7-1500-channel.110780/

aber grundsätzlich würd ich auf Probleme mit den ganzen Scripten tippen... (oder auf eins davon)

Ich würd mal in jedes Script ne APDiag-Ausgabe einbauen und mal schaun... wo das so hakt...

Ansonsten kann das an allem und nichts liegen. Hatte ähnliches Fehlerbild auch schon bei defektem 400er-CP oder defektem LWL-Medienkonverter...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin moin,
nochmals vielen Dank für eure Hilfe.

Wir haben haben heute in den Eigenschaften der CPU unter "Allgemein -> Kommunikationslast" den Wert von 20% auf 50% erhöht. Dadurch haben sich die oben genannten Probleme behoben. Die Bilder werden jetzt innerhalb der vorgegeben Zeiten aufgebaut und dargestellt. Die Zykluszeit der CPU hat sich dadurch von ca. 13ms auf 23ms erhöht. Das ist für uns kein Problem.
Diese Einstellung kann man anscheinend nur an 1500er SPSen vornehmen. Bei der 319er habe ich das nicht gefunden. Hier werden wir bald eine 1500er SPS einbauen.
Zusätzlich testen wir das bald aber noch mit einer neuen SPS mit dem Firmwarestand V3.0 (SPS mit eigenen Kommunikationsprozessor). Vielleicht kann man die Kommunikationslast dann wieder runterdrehen.

Ich gebe Bescheid wie die Ergebnisse sind. Die CPU kommt allerdings erst irgendwann im Januar.

Gruß Ralf
 
Diese Einstellung kann man anscheinend nur an 1500er SPSen vornehmen. Bei der 319er habe ich das nicht gefunden.
Bei der 319 kann man die Zyklusbelastung durch Kommunikation ebenfalls einstellen: in den CPU Eigenschaften unter Zyklus oder Zyklus/Taktmerker bei "Zyklusbelastung durch Kommunikation" (je nachdem womit die 319 programmiert wurden).

Hier werden wir bald eine 1500er SPS einbauen.
Wie DeltaMikeAir schon schrieb, können da außer den normalen Migrations-Problemen noch weitere Probleme auftreten, wenn im originalen 319-Programm die "Priorisierte BuB Kommunikation" nicht aktiviert war.
 
Hi DeltaMikeAir, hi PN/DP,
vielen vielen Dank für die Info, dass das unter Zyklus zu finden ist. Ich hätte jetzt nicht gedacht, dass diese Einstellung für eine 319er an eine andere Stelle zu finden ist. Leider wurde die Produktion schon angestellt, sodass ich das erst kommenden Montag ändern kann.
Das Migrieren haben wir zum Glück schon hinter uns. Sämtliche SPSen sind bei uns in V17.

Gruß Ralf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nur als Zusatz:

Ich hatte ein WinCC RT Projekt, da dauerte der Bild-Aufruf immer dann extrem lange, wenn das Alarm-Control mit im Bild war. Ursache war eine Migration aus WinCC V7, die im Alarmcontrol alles angehakt hatte, was nur geht. Ich hab dann alles rausgenommen und nur das nötigste angehakt, das brachte dann eine enorme Verbesserung. Trifft bei dir möglicherweise nicht zum da du ja auch PLC dabei hast, bei denen es schneller geht.

Ich würde da auch zuerst auf die Zyklusbelastung durch Kommunikation tippen und dort mal nachsehen.
 
Zurück
Oben