Wie lässt sich die Performance bei WinCCflexible steigern?

on69

Level-1
Beiträge
15
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie lässt sich die Performance von WinCCflexible steigern?

Hallo zusammen,

ich verwende eine CPU315-2 DP und eine mit WinCCflexible 2007 projektierte PC-Runtime. Als Verbindung hab ich PROFIBUS mit 12Mbit/s projektiert.
In meinem Übersichtsbild der Anlage verwende ich z. B. 50 Variablen (40 mal Byte, 10 mal Bool). Die Vorschläge aus der WinCCflex-Hilfe unter 2.7.1 hab ich eingehalten (zusammenhängender Datenbereich für den Kommunikations-DB, keine Lücken, Erfassungszyklus nicht zu klein etc.).

Ich hab allerdings das Problem, dass die Performance sehr schlecht ist. Wenn ich z. B. ein Bit in der Steuerung umschalte, braucht es ca. 3s bis dies an der HMI angezeigt wird ... das ist doch zum verzweifeln!

Wer kann mir bitte ein paar Tipps geben, wie die Performance noch zu verbessern ist. Ich bin um jeden noch so kleinen Tipp sehr dankbar!

on69
 
Zuletzt bearbeitet:
In meinem Übersichtsbild der Anlage verwende ich z. B. 50 Variablen (40 mal Byte, 10 mal Bool). Ich hab allerdings das Problem, dass die Performance sehr schlecht ist. Wenn ich z. B. ein Bit in der Steuerung umschalte, braucht es ca. 3s bis dies an der HMI angezeigt wird ... das ist doch zum verzweifeln!
Da Du nicht so viel Variablen hast kannst Du folgendes probieren.
Bei denen, oder nur bei einigen die wirklich schnell sein müssen, denn Erfassungszyklus auf 100ms stellen.
Wenn Du das allerdings bei sehr vielen machst wird es eher wieder langsamer.

Variablen > Eigenschaften > Allgemein > Erfassungszyklus
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
vorweg ... ich bin nicht Paules Meinung. Bei einem 12MBit Profibus und so ein paar Variablen müßte die B&B-Verbindung (Bedienen und Beobachten) super funktionieren.
Wenn es aber dennoch nicht so ist so nehme ich an, der der PB mit seiner eigentlichen Aufgabe so viel zu tun hat, dass die Visu "hinten an" gestellt wird - ist bei PB nunmal so ...

Kannst du das Bediengerät spaßeshalber an den MPI hängen ?

Gruß
LL
 
Jetzt benutze ich eine Test-SPS am Arbeitsplatz und verwende das Siemens-PG als PC-Runtime. Später wird ein Rechner mit einer CP5611-PCI-Karte eingesetzt als Schnittstelle für den Profibus.

Übrigens, den Vorschlag von Larry hab ich umgesetzt und die Geschwindigkeit hat sich schon mal wesentlich verbessert (obwohl noch einiges wünschenswert wäre).

Hat jemand damit Erfahrung, wie es wäre die Verbindung über Ethernet herzustellen? Z. B. CPU mit Profinet-Anschluss bzw. CP343. Könnte man damit eine schnellere Verbindung erreichen?
____________
on69
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das MPI/DP Schnittstelle auf ein Siemens PG soll ein CP5611 entsprechen.

Ich verwende nur PN CPUs, und bin sehr glücklig damit. Mehrere HMIs und PCs gleichzeitig online ist kein Problem (bei 4 HMIs/PCs online gibt es keine spürbare verringerung von den Aktualisierung). Die mesiten von meine Tags haben 1 Sekunde aktualisierung. Einige haben 400 ms.
 
Hallo,
Ethernet ist nur dann ein Vorteil, wenn er so wie von Jesper beschrieben (oder alternativ VIPA-CPU) zustande kommt. Ein CP343 bringt da nichts, da die höhere Busleistung durch den schwachen Rückwandbus der SPS mehr als kompensiert wird ...

Zum Punkt MPI nochmal :
Wie hast du denn das Intervall deiner 50 Variablen eingestellt ?
Ich würde hier auf gar keinen Fall unter 0,5 Sek. gehen - eher 1 Sek. - manchmal ist weniger dann doch mehr ... ;)

Gruß
LL
 
Kann es sein, dass Du Variablenarchive verwendest?
Ich hatte mal mit einem Projekt zu tun, bei dem, warum auch immer, Variablen in Archive geschrieben wurden. Das hat die Performance des Bediengerätes sehr stark negativ beeinflusst. Es handelte sich um ein MP270(B), später ein MP277, zunächt per MPI oder Profibus, später auf Ethernet angeschlossen.

Gruß Rolf
 
Kann es sein das dein Program fast leer ist ?

Bei S7 ist den lustige Verhältnis, das wenn den CPU Programzyklus ganz kurz ist (1 ms oder so) dann gibt es wenig Zeit vorüber um "Kommunikationsaufgaben" zu beseitigen. Man sollte sich vermuten das wenn den CPU nur wenig Zeit für den normalen Programablauf verwendet, dann bleibt es mehr Zeit für Kommunikation. Aber es verhält sich umgekehrt (!).
Dies gilt wenn den CPU selber den Kommunikation verwaltet. Also MPI und onboard PN Schnittstellen.

Auf ein S7 CPU gibt es ein HW Parameter "Scan cycle load from communication [%]". Dies is als Standard auf 20% eingestellt. Im schwierigen Fall kan man versuchen diese Wert zu erhöhen.
 
@Jesper:
Für das, was du schreibst hatte es dann extra mal von Siemens den "verlängere Zykluszeit-FB" gegeben (Nummer weiß ich nicht mehr). Ich hatte das auch mal bei einer meiner Anwendungen getestet - hatte nichts gebracht. Auch nicht bei Programm-Zykluszeiten im Bereich von 1 ms ...

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In meinem Programm ist derzeit noch nicht viel drin. Die Zykluszeit beträgt ca. 10-20 ms. Das Verändern des Parameter "Zyklusbelastung durch Kommunikation" (von 20% auf 50%) hat keine wesentliche Änderung gebracht.

@Larry: Den Erfassungszyklus der Variablen hab ich auf 1s eingestellt (da alles darunter das Ergebnis eher schlechter macht).

Ein Problem hatte ich noch nicht erwähnt: Manchnmal (so jeder 10. Klick) nimmt die HMI den Befehl nicht an, was natürlich für den Bediener auch kaum zumutbar ist.

Ansonsten möchte ich an dieser Stelle einfach ein DICKES LOB an Euch loswerden für die schnelle und kompetente Hilfe!!!
 
on69 schrieb:
In meinem Programm ist derzeit noch nicht viel drin. Die Zykluszeit beträgt ca. 10-20 ms.
Ich habe auf ein 315-2PN/DP mit sehr viel Program drinnen ein Zukluszeit von ungefähr 8-12 ms.
Mit 10-20 ms, und "nicht viel drin" glaube Ich das es ist ein sehr alte CPU. Vielleicht mit Batterie und MC Karte ?

on69 schrieb:
Manchnmal (so jeder 10. Klick) nimmt die HMI den Befehl nicht an, was natürlich für den Bediener auch kaum zumutbar ist.
In den HMI nur "Bit setsen" verwenden. Nicht Setsen und Rücksetsen.
In den SPS, bit auswerten um funktion auszulösen, und schlieslich bit rücksetsen.
 
Wichtig bei HMI über Profibus ist auch das Profibus-Protokoll.
Standardmässig ist normalerweise "DP" eingestellt. Stell hier mal auf "Standard" oder "Universell (DP/FMS)". Damit legst du im Prinzip fest welchen Prozent-Anteil die HMI-Kommunikation an der gesamten Kommunikation haben darf.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Problem hängt mit Zykluszeit zusammen

Hallo zusammen,
ich hab die verschiedensten Einstellungen durchprobiert und bin nach vielem Ausprobieren dem Problem näher gekommen. Die schlechte Performance hängt eindeutig mit der Zykluszeit der CPU zusammen.

Bei ca. 15ms Zyklus dauert das "Umschalten eines Bits an der HMI" ca. 2 Sekunden (dies ist dem Kunden nicht zumutbar).
Bei ca. 8 ms Zyklus dauert der gleiche Befehl nur ca 0,5s und ist somit OK.

Ich kann mir den Effekt allerdings nicht erklären. Wer hat einen Tipp woran es liegen könnte??? Wieso wirken sich diese 7ms so stark auf die Performance bei der Darstellung an der HMI aus?

Aktuelle Einstellungen:
Erfassungszyklus der Variablen an der HMI 1s; Zylklisch bei Verwendung
Verbindung Profibus DB 1,5 MBaud
Zyklusbelastung durch Kommunikation an der CPU 20% (50% hat nichts gebracht)
_______
on69
 
Nur mal so ein Gedanke, du hast doch die runtime auf
deinen PG. Vielleicht liegst es ja daran das du deine
Projektierunssoftware auf hast und somit der Rechner
bzw das ganze System langsam wird.
Wie sieht es eigentlich mit der Hardware konfig auf CPU
Seite aus, sind da schon PB Teilnehmer projektiert.
Auf jedem Fall muss dein System, bei deiner Beschreibung
wesentlich schneller sein.
 
Die Zykluszeiten "mit nicht viel drinnen" finde Ich verdächtig.
Es wäre auch interessant zu wissen, genau welchen Typ CPU.
Wie gefragt in post # 13.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann es sein das dein Program fast leer ist ?

Bei S7 ist den lustige Verhältnis, das wenn den CPU Programzyklus ganz kurz ist (1 ms oder so) dann gibt es wenig Zeit vorüber um "Kommunikationsaufgaben" zu beseitigen. Man sollte sich vermuten das wenn den CPU nur wenig Zeit für den normalen Programablauf verwendet, dann bleibt es mehr Zeit für Kommunikation. Aber es verhält sich umgekehrt (!).
Dies gilt wenn den CPU selber den Kommunikation verwaltet. Also MPI und onboard PN Schnittstellen.

Auf ein S7 CPU gibt es ein HW Parameter "Scan cycle load from communication [%]". Dies is als Standard auf 20% eingestellt. Im schwierigen Fall kan man versuchen diese Wert zu erhöhen.

Oder man stellt eine größere minimale Zykluszeit ein, dann sollte die Kommunikation auch genügend Zeit zur Verfügung haben.
 
Nochmal eine kurze Beschreibung wegen meinem Performanceproblem:

Verhalten beim Setzen eines Bits an der HMI bis die Rückmeldung an die HMI erfolgt:
- bei ca. 14ms Zykus und wenig Variablen pro Bild (6Byte): schnelle Reaktion, alles OK
- bei ca. 14ms Zykus und 100Byte pro Bild: Reaktion zu langsam ca. 2S, ignoriert auch jeden ca. 5-ten Mausklick-Befehl.
- bei ca. 8ms Zyklus: schnelle Reaktion, alles OK, auch bei 100Byte/Bild
(die Zykluszeit verändere ich, indem ich einen Teil des Codes ausklammere)

Das Verhalten ändert sich nicht wesentlich in folgenden Fällen:
- Umschalten der Baudrate bzw. des Protokolls bei Profibus
- Verändern der Verbindung von Profibus/MPI
- Verändern des Erfassugszyklus der Variablen in WinCCflex
- Verändern "Zyklusbelastung durch Kommunik." an der CPU
- entfernen aller Bitmeldungen aus WinCCflex, keine Variablenarchive, keine Bildbausteine

@Helmut: Hab schon alles ausgeschatlet bis auf Runtime - leider keine wesentliche Verbesserung
@Jesper: CPU515-2DP (315-2AG10-0AB0) mit ET200 (IM151-1 Standard mit ein paar IO-Modulen)
@Ralle: Da 300er CPU - minimale Zykluszeiteinstellung nicht möglich

Ich weiß leider nicht wo das "Nadelöhr" ist. Auf Runtime-Seite, in der Kommunikation oder der CPU?
Was für mich völlig unlogisch ist, ist die Tatsache dass ca 6ms Zykluszeitverlängerung die Performance um ca. 1,5 Sekunden verschlechtert!
_______________
on69
 
Noch mal zu den Variablen, wie hast du die Erfassungsart eingestellt und
vor allen dingen die der Tasten die du dann prüfst.
Normal reicht es ja aus für Variablen die nicht getastet werden eine Zeit
von 1s einzustellen, bei den die eine Tast funktion haben nehme ich immer
500msec.
 
Zurück
Oben