WinCC sehr träge

Hallo zusammen,

ich sitze hier vor einem WinCC System und wundere mich, warum das so extrem träge zu bedienen ist.
Beispiel: ich drück nen Knopf und halte ihn gedrückt, in meinem Programm sehe ich es so nach 1,5-2 Sekunden.
Das kann doch so nicht richtig sein...
Könnt Ihr mir Tipps geben, wie ich jetzt herausfinde, warum das so lange braucht?

Das System sieht wie folgt aus:

PC-Rechner mit Core-i-7 3,0 Ghz + Windows 7 Professional 64bit, 8Gb Ram
WinCC 7.2 Update 10
12.000 Tags
Anbindung per TCP/IP

Auf der Bedienseite wird die Variable per "Direktverbindung" angebunden.

Im Variablenhaushalt -> Systemparameter TCP/IP:
Zyklus bildung durch AS = JA
mit Änderungsübertragung = JA

irgendeine Information vergessen?

gruss Markus

Hi,

kenne mich mit WinCC direkt nicht aus, aber was sagt denn der Task Manager, wie sieht die CPU Auslastung aus?

jo, Speicherauslastung 20-25%, CPU Auslastung unter 10% (8 Kerne, keiner höher wie 20% belastet)

Da läßt sich m.E. nicht allzu viel pauschal dazu sagen.

Was mir so einfällt (ohne mich aber mit den Eigenarten von WinCC auszukennen) :

- Wie viele Variablen werden zeitgleich mit welcher Aktualisierungsrate angefragt ?
- Was hängt sonst noch so dran am Ethernet ?
- Was für eine CPU ?

Gruß
Larry

Servus,

wie lange benötigt die Runtime zum starten?

Was passiert denn beim Knopf drücken, und was soll in der SPS landen?

Sind die 12000 Tags alle auf einer CPU, oder auf 20 verteilt?
Wie ist das Alarmlogging eingerichtet: Bausteinbezogene Meldungen, oder bitgetriggerte Meldungen?

Es könnte sein, dass im Hintergrund so viel zyklische Variablen abgefragt werden, dass für die restliche Kommunikation nur wenige Bandbreite überbleibt.

Zu den zyklischen Variablen gehören z.B. alle Variablen die im Alarmlogging oder im Taglogging verschaltet sind. Werden dort so viele Variablen abgefragt, und die Bandbreite bzw. die Kommunikationsleistung der Steuerung ist relativ gering (300er CPU mit Ethernet-CP ist sehr langsam), dann ist sehr schnell der Fall dass für die restliche Kommunikation keine Reserve mehr bleibt (da diese nachrangig behandelt wird).

Ungünstige Auswirkungen haben auch unsinnig geringe Aktualisierungszeiten von Variablen im Tagloggin wie 500 ms. Hierbei ist es fast immer von Vorteil, die Aktualisierungszyklen möglichst gleich einzustellen damit die Anfragen in ein Telegramm gepackt werden können.

Anlaufpunkt für eine erste Diagnose ist die "WinCC Channel Diagnosis" aus dem WinCC Programme/Tools-Ordner. Dort kannst du sehen wie viele Variablen in welchem Aktualisierungszyklus abgefragt werden sollen, und auch die letzten Antwortzeiten für Lese- und Schreibanfragen. Du kannst ja mal aufschreiben welche Werte du dort angezeigt bekommst.

Die Idee von Thomas ist schon sehr gut. Als erstes würde ich mir aber mal die Größe der Datenbank im Arbeitsspeicher angucken (sqlsrv.exe). Kenne das Problem von unseren Anlagen dass die Datenbank mit der Zeit voll läuft und somit extrem inperfomant wird - betrifft auch die Kommunikation zwischen Datenhaltung und Kommunikationsfunktionen. Unser richwert liegt bei Ca. 1,5-2GB (Bei knapp 45000 Variablen, ohne Taglogging). Dieses Aufblähen sowie die Auswirkungen auf Kommunikation und Archivzugriffe sind ein bekanntes Verhalten der Datenbank.

Gesendet von meinem HTC One_M8 mit Tapatalk

Die Channel Diagnose war der Tipp, hatte ne Read Response von 180ms und ne Queue von 50-60... Die Queue ist das eigentliche Problem. Hab zuerst mal die Visu von der CP auf die CPU direkt gehangen, Read Response ist nun 50ms. Das hat schon mal einiges gebracht... Dann hab ich angefangen die 250ms Trigger gegen 1sec Trigger zu tauschen. Bin jetzt bei einer Queue von 33 angekommen. Leider stellen wir viele Dinge dar, entsprechend bin ich noch nicht komplett fertig damit.

Gesendet von meinem SM-G925F mit Tapatalk