# Wie lässt sich die Performance bei WinCCflexible steigern?



## on69 (22 März 2010)

*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


----------



## Paule (22 März 2010)

on69 schrieb:


> 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


----------



## Larry Laffer (22 März 2010)

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


----------



## JesperMP (22 März 2010)

Und wie kommt der PC auf Profibus ?


----------



## on69 (22 März 2010)

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


----------



## JesperMP (22 März 2010)

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.


----------



## Larry Laffer (22 März 2010)

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


----------



## R.Blum (22 März 2010)

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


----------



## on69 (22 März 2010)

R.Blum schrieb:


> Kann es sein, dass Du Variablenarchive verwendest?
> 
> Gruß Rolf


 
Daran liegt es nicht, ich verwende keine Variablenarchive.
_____________
on69


----------



## JesperMP (22 März 2010)

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.


----------



## Larry Laffer (22 März 2010)

@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


----------



## on69 (22 März 2010)

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!!!


----------



## JesperMP (22 März 2010)

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.


----------



## Blockmove (22 März 2010)

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


----------



## on69 (24 März 2010)

*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


----------



## rostiger Nagel (24 März 2010)

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.


----------



## JesperMP (24 März 2010)

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.


----------



## Ralle (24 März 2010)

JesperMP schrieb:


> 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.
> ...



Oder man stellt eine größere minimale Zykluszeit ein, dann sollte die Kommunikation auch genügend Zeit zur Verfügung haben.


----------



## on69 (25 März 2010)

*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


----------



## rostiger Nagel (25 März 2010)

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.


----------



## JesperMP (25 März 2010)

Die "100 Bytes", sind die als Einsel-Tags konfiguriert, oder als Array-Tags konfiguriert ? 

Das "Nadelöhr" kann den Profibus Bus-Profil sein.
Ist den HMI in den STEP7 Projekt integriert ? Also, den HMI wird mit-berechnet in den Profibus Bus-Profil ?
Es ist nicht genug eine freie Stationsadresse zu finden, und dann in ein eksistierende Profibus-Netz einzustecken.
Und welche Profibus Bus-Profil Typ wird verwendet ? "DP" oder "Standard" ?


----------



## JesperMP (25 März 2010)

Helmut_von_der_Reparatur schrieb:


> 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.


Genau das vermeide Ich wenn möglich. 

Aus post # 13:


			
				JesperMP schrieb:
			
		

> 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.


Dies bewirkt das die Tastern funktioniert selbst bei lange Aktualisierungszeiten.


----------



## rostiger Nagel (25 März 2010)

sag mal jasper,
wie ist das den bei Tippbetrieb? Wenn ein Antrieb solange laufen
soll wie die Taste betätigt ist.


----------



## JesperMP (25 März 2010)

Ich habe sehr selten "Tippbetrieb".

Wenn ich es habe, soll es ja auch nicht nur 500 ms fahren.
Wenn ich es habe, verwende ich auch "Bit Setsen" und "Bit Rücksetsen", und dazu eine Timerüberwachung.

Wenn man "tippen" will mit ein genauigheit von 500 ms, dann versucht man etwas zu tun mit ein Windows Funktion die ich nicht vertrauen wurde.
In den Fall wurde ich es anders lösen.


----------



## PN/DP (25 März 2010)

*Tippbetrieb per Panel nur ganz selten*

Ich mache es auch grundsätzlich so wie Jesper, daß ich die Tastenbits in der HMI-Runtime nur setze und am 
Ende des OB1 in der CPU lösche. Ein Tippbetrieb geht so natürlich nicht.

Wenn ich mal Tippbetrieb brauchte, dann waren das aber nur sehr wenige Bits, die solange wie gedrückt in der 
CPU anstehen bleiben mußten.
Tippbetrieb mache ich außerdem grundsätzlich nur, wenn in direkter Nähe des Panels ein Hardware-Stopptaster
oder Notaustaster vorhanden ist, mit dem man die Antriebe stoppen kann, falls genau während dem Tippen die 
Kommunikation vom Panel zur CPU zusammenbricht. Ich traue dem Tippen über Netzwerke nicht so ganz.
Hardware-sicher ist das wohl nur mit Mobile Panels oder mit Panels mit Profibus-Direkttasten machbar.

Leider habe ich in WCF noch keine praktikable Möglichkeit gefunden, einen repetierenden Taster zu erstellen, 
der alle 50...100ms das Setzen eines Bits in der CPU wiederholt. Dann könnte man nähmlich eine Ausschalt-
verzögerung programmieren und wäre nicht mehr darauf angewiesen, daß der Rücksetzbefehl vom Panel auch in 
der CPU ankommt.

Gruß
Harald


----------



## JesperMP (25 März 2010)

Es ist nicht nur den Verbindung zwisschen PC und SPS das mir erschreckt.
Es ist alles das mit ein "normalen" PC passieren kann. Selbst "blöde" Fehler, wie das Tastatur-Kabel aus den PC zu ziehen auf den falschen Zeitpunkt.
Oder hat ihr erlebt das ein Taster hängend bleibt ? Zum beispiel bei normalen oder sogar "industrielle" Tastaturen in Industriellen Umfeld ?


----------



## PN/DP (25 März 2010)

Oder an eine Variable ist "bei Änderung" ein Bildwechsel projektiert, und die ändert sich gerade während eine Taste gedrückt ist ...
Oder ein irgendwie programmierter Benutzer-Logout kommt dazwischen. Oder ein Firmwarefehler. Oder der Bediener drückt mit einem 
spitzen Gegenstand die Taste und dabei die Touchfolie kaputt. Oder ... [EDIT] Oder ein Meldefenster popt auf ... [/EDIT]
Also ich vertraue nicht darauf, daß die WCF-Runtime garantiert immer ein "Taste losgelassen" an die CPU schickt.

Gruß
Harald


----------



## Larry Laffer (25 März 2010)

Naja ... unabhängig von all dem sollte natürlich die eigentliche Steuerung bei jeder Form des Tipp-Betriebs mit INI's oder Endschaltern etc. jeden Vorgang absichern.

Wegen dem Quittieren eines Bits - wir hatten da mal einen Elite-Uni-User, der hätte den Arsch seiner Großmutter darauf verwettet, das Flex das IMMER hinkriegt. 
Aber davon mal abgesehen - Wenn das Flex doch so Sch.... ist, wie ihr (alle) immer schreibt (auch ich habe ein etwas gestörtes Verhältnis dazu) - warum schiessen wir dann nicht mal alle zusammen Herrn S. in die Füsse ?

Gruß
LL


----------



## rostiger Nagel (25 März 2010)

Larry Laffer schrieb:


> Naja ... unabhängig von all dem sollte natürlich die eigentliche Steuerung bei jeder Form des Tipp-Betriebs mit INI's oder Endschaltern etc. jeden Vorgang absichern.
> 
> Wegen dem Quittieren eines Bits - wir hatten da mal einen Elite-Uni-User, der hätte den Arsch seiner Großmutter darauf verwettet, das Flex das IMMER hinkriegt.
> Aber davon mal abgesehen - Wenn das Flex doch so Sch.... ist, wie ihr (alle) immer schreibt (auch ich habe ein etwas gestörtes Verhältnis dazu) - warum schiessen wir dann nicht mal alle zusammen Herrn S. in die Füsse ?



ich bin pazifist und habe keine Waffe!

aber irgendwie hast du recht, ich würde mich schon für ein anders
Visualisierungs Werkzeug intressieren, aber welches?
Wenn ich ein anderes auswähle muß ich mich absolut darauf verlassen 
können das es funktioniert, ich möchte nicht nach einen halben Jahr
merken, das ich ein Werkzeug habe was auch seine Macken hat aber
nur andere wie flexibel.

Gestern hatte ich wieder ein schönes erlebnis mit Flex, ich habe den halben
Tag konzentriert an einen projekt gearbeitet. Auf einmal funktionierte 
nichts mehr und ich idiot hatte nicht zwischengespeichert.

Im gegensatz zu mein Einleitungssatz wollte ich jemanden umbringen.


----------



## JesperMP (25 März 2010)

@LL

Das hilft nicht wenn das was man transportieren oder bewegen will, zu schaden führen kann, obwohl kein End-Position erreicht ist.

Ich war einmal in ein Projekt wo es ein Tippbetrieb gab, aber mit eine "Echte" Taster. Diese Taster ist dann hängend geblieben ---> 5 tonnen schmolzene Eisen auf den Flur ! Es passierte ganz schnell, bevor den Operator den Not-Aus aktivierte.

Zeitdem bin ich sehr achtsam bei Tippbetrieb. Ich habe letzte mal ein Dreh-Schalter mit Feder-retur. Bei ein Dreh-Schalter kann man mit Kraft den Schalter zurück drehen, das geht nicht bei ein Taster. Wenn es sehr gefärlich wäre, wie in obengenannte Fall, wurde ich dobbelte Kontakte abtesten (Schliesser und öffner), eventuell über ein Sicherheitsrelais.


----------



## Larry Laffer (25 März 2010)

Es gibt nicht wirklich eine Alternative - das ist schon DER PUNKT ... aber muß man sich von den Jungs immer und alles gefallen lassen ? Und das Schlimmste dabei - die denken alle, dass sie die größten waren, sind und immer sein werden. Was meinst du, warum ich nach wie vor das Meißte mit ProTool mache - das ist zwar schon seit 5 Jahren nicht mehr weiterentwicklet worden, aber irgendwelche Bugs in der Art, wie ich sie bei Flex ständig finde (und ihr ja auch), sind da gar nicht erst drin - und die 2 oder 3 Dinge, die es gegenüber Flex nicht kann, die kann ich verschmerzen ... 

Ich habe (leider) keine Idee, was man gegenüber Siemens da machen kann, aber immer wenn ich da mal mit einem von denen spreche, dann sagen die zu mir, dass sie das zum ersten mal hören - vielleicht stimmt das sogar und ich bin der einzige Renegard ...


----------



## Larry Laffer (25 März 2010)

JesperMP schrieb:


> Ich war einmal in ein Projekt wo es ein Tippbetrieb gab, aber mit eine "Echte" Taster. Diese Taster ist dann hängend geblieben ---> 5 tonnen schmolzene Eisen auf den Flur ! Es passierte ganz schnell, bevor den Operator den Not-Aus aktivierte.
> 
> Zeitdem bin ich sehr achtsam bei Tippbetrieb. Ich habe letzte mal ein Dreh-Schalter mit Feder-retur. Bei ein Dreh-Schalter kann man mit Kraft den Schalter zurück drehen, das geht nicht bei ein Taster. Wenn es sehr gefärlich wäre, wie in obengenannte Fall, wurde ich dobbelte Kontakte abtesten (Schliesser und öffner), eventuell über ein Sicherheitsrelais.


 
OK ... aber bei so einer Sache würde ich das dann aber auch nicht über die Visu - egal welche - steuern ...


----------



## JesperMP (25 März 2010)

@LL.
Wenn es kein "böses" passieren kann, mit Personen oder Material, dann wurde ich vermutlich auch ein Tippbetrieb in den Visu machen.


----------



## PN/DP (25 März 2010)

Helmut_von_der_Reparatur schrieb:


> ich würde mich schon für ein anders Visualisierungs Werkzeug intressieren, aber welches?


Ob das wesentlich was bringt?
Unter der neuen "sichereren" Visualisierung werkelt dann wahrscheinlich immer noch irgendein Windows ... und MS vertraue ich da noch weniger als dem petrol-farbenen S.

Gekappte Kommunikationskabel kann keine Visu-Software verhindern.
Aber bei einem Profibus/Profinet-Direkttastenmodul würde bei Bruch des Kommunikationskabels das Bit in der CPU gelöscht werden.

Das Thema nimmt hier ja eine interessante Wendung von "wie kann man die Performance von WCF steigern?" zu "kann man WCF überhaupt einsetzen und vertrauen?".

Gruß
Harald


----------



## rostiger Nagel (25 März 2010)

Stimmt das Thema wendet sich, wie so oft. 
Aber überlegt mal mas ihr hier so schreibt, ihr
vertraut flex oder Windows nicht mal einen tippbetrieb
zu, das kann doch nur heißen, das wir ganz andere Sachen
auch nicht machen dürfen. Zb die hmi gibt ein falsches
Mischungsverhältnis an die Steuerung und es ensteht ein
explosives Gemisch. Oder bei dir Harald eine falsche soll-
Temperatur und der ganze Fischfang einer Woche wird 
auf 30 Grad geregelt, wenn oder was wollen wir da noch
trauen?


----------



## JesperMP (25 März 2010)

HvdR.
Fehlern in den Art wie Du beschreibst, wo es funktioniert aber mit eine Falsche Funktionsweise, kommen nicht "plötzlich". Wenn es ein Software-Bug gibt, seht man es _oft_ sofort bei den erste Test. 
Aber ein Fehler in der Art wo etwas komplett aufhört zu funktionieren kann vorkommen von eine Menge von Ursachen. Und bei Windows PC's ist die mögliche Fehler-Quellen um ein Faktor 100 Grösser als bei ein System mit nur SPS und Festverdrahtete Elektrische Komponente.

Zurück zum Thema.
Ich Frage nochmals über den Variablen-Struktur (Einsel-Tags oder Array-Tags), und Profibus Bus-Profil.
In meine Projekte kann es bis 200 Bytes in ein Bild aktiv sein, und mehrere PCs können gleichzeitig online sein. Das auf ein 315-2PN/DP in denselbe Generation wie den genannte 315-2DP.
Ich verwende Ethernet, aber glaube trotzdem das 100 Bytes auf Profibus soll möglich sein.


----------



## Backdoor (25 März 2010)

on69 schrieb:


> 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).
> on69




Hallo

Also hast du schon mal überprüft ob du da nicht ein NW Prpoblem hast??

Hab auch eine VIS mit WIN Flex 2008 laufen auf 4 PC´s und 1388 verw Powertags und es läuft einwandfrei!

Lg Backdoor


----------



## Larry Laffer (25 März 2010)

JesperMP schrieb:


> Ich verwende Ethernet, aber glaube trotzdem das 100 Bytes auf Profibus soll möglich sein.


 
Nein Jesper,
Profibus und MPI sind vom Durchsatz her etwas vollkommen anderes, wie Ethernet - speziell der von dir benutzte PN ...
Am PB werden die B&B-Dienste so nebenher mitgeführt - Priorität haben hier aber die DP-Geschichten (also EA's etc.). MPI ist von sich aus langsam - gehört aber dann meißt der Visu ganz allein. Hier kann es also sein (so meine Erfahrung), dass der MPI trotz niedrigerer Baudrate schneller als der PB mit DP-Stationen für die Visu ist.
PN (speziell auf einer PN-CPU) hat eine sehr hohe Baudrate und das Ganze noch zusätzlich direkt an die CPU gekoppelt. Ich würde den Leistungsvorteil hier (gegenüber MPI 1:1) mit dem Faktor 20 oder höher (nach meiner Erfahrung) bewerten ...

Gruß
LL


----------



## Backdoor (25 März 2010)

Larry Laffer schrieb:


> Nein Jesper,
> Profibus und MPI sind vom Durchsatz her etwas vollkommen anderes, wie Ethernet - speziell der von dir benutzte PN ...
> Am PB werden die B&B-Dienste so nebenher mitgeführt - Priorität haben hier aber die DP-Geschichten (also EA's etc.). MPI ist von sich aus langsam - gehört aber dann meißt der Visu ganz allein. Hier kann es also sein (so meine Erfahrung), dass der MPI trotz niedrigerer Baudrate schneller als der PB mit DP-Stationen für die Visu ist.
> PN (speziell auf einer PN-CPU) hat eine sehr hohe Baudrate und das Ganze noch zusätzlich direkt an die CPU gekoppelt. Ich würde den Leistungsvorteil hier (gegenüber MPI 1:1) mit dem Faktor 20 oder höher (nach meiner Erfahrung) bewerten ...
> ...




Hallo,


@Larry  RESPEKT der MAnn weiss von was er redet!!!


Lg Backdoor                        *ACK*


----------



## JesperMP (25 März 2010)

@LL

Ich verstehe das Ethernet viel performanter ist als Profibus.
Aber wie geschrieben: "glaube trotzdem das 100 Bytes auf Profibus soll möglich sein".

Wenn den PC RT nicht richtig in Profibus eingetragen ist, wird es kein "platz" für die Daten für den PC reserviert.
Es kann vielleicht funktionieren bei kleine Datenmengen, aber bei grössere Datenmengen wird den Datentransfer gedrosselt.
Und, es hilft nicht den baudrate von 1.5M auf 12M zu erhöhen.


----------



## on69 (25 März 2010)

Sorry für die späte Rückmeldung, war auf Reparatur...

@Jesper - meine 100Bytes hab ich auf SPS-Seite als Array of Bytes definiert, auf WinCCflex-Seite als 100 Einzelvariablen vom Typ Byte.
Alle 100 Bytes mächte ich in einem Bild darstellen können... geht, aber wie gesat einfach zu langsam.
- das Profibus Profil "Standard" scheint ein bisschen schneller als "DP" zu sein - bringt aber keine richtige Lösung

@Larry - verstehe ich Dich richtig, dass eine CPU mit PN-Anschluss mein Problem evtl. löst (sprich die Übertragungsgeschwindigkeit wesentlich steigert)?

@Backdoor - ob ich ein Netzwerkproblem hab weiß ich (noch) nicht, hab in NetPro eine HMI-Station mit CP611 und WinCCflex RT projektiert an Profibus angebunden und fertig.
(Habs auch mit MPI versucht - kein vesentlicher Unterschied in der Performance)

hab übrigens aus WinCCflex alles entfernt bis auf die besagten 100Variablen die in einem Fenster angezeit werden (keine Skripte, Archive, Bitmeldungen etc.)
_______
on69


----------



## rostiger Nagel (25 März 2010)

PN ist mit Sicherheit schneller, aber was meinst du mit
entfernt. Leg doch mal ein neues Projekt an, mit deinen
Var. die Wege von flexibel sind ja unergründlich.


----------



## Backdoor (25 März 2010)

Was du ev. noch probieren könntest im Wincc flex wäre unter Extras ----> temporäre Dateien löschen, dann neu generieren.

lg Backdoor


----------



## JesperMP (25 März 2010)

on69 schrieb:


> @Jesper - meine 100Bytes hab ich auf SPS-Seite als Array of Bytes definiert, auf WinCCflex-Seite als 100 Einzelvariablen vom Typ Byte.
> Alle 100 Bytes mächte ich in einem Bild darstellen können... geht, aber wie gesat einfach zu langsam.


Was etwas bringen wurde, wäre eine ARRAY Tag in Flex zu definieren.
Du kannst einfach versuchen ein neue ARRAY Tag zu definieren, und dann in ein neues Bild diese ARRAY Tag zu verwenden. Wenn du nur eine Element verwendet ist egal, es belastet den Datentransfer gleich, weill den gesammte ARRAY auf einmal geladen wird. Dann vergleich den Geschwindigheit mit dein Bild mit 100 Einsel-Tags.



on69 schrieb:


> - das Profibus Profil "Standard" scheint ein bisschen schneller als "DP" zu sein - bringt aber keine richtige Lösung
> [..]
> hab in NetPro eine HMI-Station mit CP611 und WinCCflex RT projektiert an Profibus angebunden und fertig.
> (Habs auch mit MPI versucht - kein vesentlicher Unterschied in der Performance)


Es lautet so weit Richtig. 
Also, den HMI-Station ist im selben STEP7 Projekt als den 315-2DP CPU ?


----------



## JesperMP (25 März 2010)

Nur als Beispiel:
Ich habe ein Projekt mit ein 319-3PN/DP, und 2 Profibus Netze, die fast gleich sind. 

Auf eine Netz nur DP slaves und Busprofil DP. Hier ist TTR = 22.7 ms.

Auf das andere Netz gibt es DP Slaves und auch ein TP Panel, und Busprofil Standard. Hier ist TTR = 109.3 ms.

Also, 5 mal so viel Buszykluszeit ist reserviert, nur um diese eine TP Panel.
Und dies bedeutet auch das das TP Panel genügend Bandbreite für den Datenaustausch hat. Nachteil ist das die Slaves aktualisieren wesentlich langsahmer. In meinem Fall ist es aber Akzeptabel (*).
In werklichen Betrieb ist den Token Rotaion time wesentlich kürzer. Aber diese reservierte Bandbreite ist notwendig für den TP.

*: Und das Panel hängt nur auf Profibus weill ein Kollega von mir nicht 80 m Ethernet Kabel legen will.

Es wäre für mich interssant zu wissen alle Details über den Profibus konfiguration, und was für ein TTR das berechnet ist.


----------



## Blockmove (25 März 2010)

Ich handhabe es so:
Einfache Visu mit an den Profibus. Evtl. das Protokoll von DP auf Standard umstellen.

Umfangreichere Visu an MPI. Die 187,5kBaud stehen exklusiv der Visu zur Verfügung. Ist eigentlich immer schneller als Profibus.

Bei DP/PN-CPUs die Visu an den jeweils nicht benutzen Strang.

Gruß
Dieter

FB_Addon_TelNo{ height:15px !important;  white-space: nowrap !important;  background-color: #0ff0ff;}


----------



## on69 (26 März 2010)

*Lösung gefunden!*

Hallo zusammen,

ich habe das Problem mit der schlechten Performance beheben können!
Offensichtlich hing meine langsame Verbindung damit zusammen, dass ich die CPU schon seit Monaten für diverse Testprogramme benutze.
Heute hab ich in Anlehnung an den Vorschlag von Helmut die CPU mal urgelöscht, alles neu rauf, und siehe da die Verbindung ist schnell geworden. Der Zyklus ist nach vie vor bei ca. 15ms geblieben, aber vielleicht war das Programm irgendwie zerstückelt im Arbeitsspeicher angesiedelt, so dass sich dies auf die Kommunikation auswirkte.

Ich möchte an dieser Stelle Euch allen ein ganz dickes Lob aussprechen, für die schnelle Hilfe, und das hartnäckige Dranbleiben am Lösen des Problems.
Ich verstehe zwar nicht wo Ihr die Zeit (und Lust) dazu hernehmt, aber mir hat es sehr geholfen.
Wenn es sowas wie eine virtuelle Eiskasse gibt, dann sagt mir wo, ich gebe eine Runde aus!
_____________
on69


----------

