TIA Abschätzung der "Zyklusbelastung durch Kommunikation" möglich?

[Raijin Tycho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin zusammen,

gibt es eine gute Möglichkeit die "Zyklusbelastung durch Kommunikation" abzuschätzen / zu simulieren? Oder kann man nur versuchen das ganze anhand des vorhandenen Systems und zu erwartenden Programms zu schätzen?

 

[DeltaMikeAir]

Schau mal hier ab Seite 32:
https://www.google.com/url?sa=t&rct...ownload=true&usg=AOvVaw1_D1pVBHIBxhpgYs8FtCde

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auf Seite 39 wird auch gezeigt, wie man eine Prognose erstellen kann

 

[vollmi]

Auf Seite 39 wird auch gezeigt, wie man eine Prognose erstellen kann

Ich hab das auch schon versucht zu interpretieren. Wirklich schlau bin ich daraus nicht geworden. Hier zum vergleich.
Zwei CPUs eine 1515 und eine 1517. Beide haben das exakt gleiche Programm mit Webserver und OPC am rennen.
OPC hab ich 1000 DINT abonniert welche jeden zyklus incrementieren. Zugleich eine Anwenderseite online welche die CPU zuballert was nur geht.

Die 1515 lässt sich ohne Probleme auf die 50% zykluserhöhung belasten. wenn die Kommunikation weg ist, ist der Zyklus wieder auf der hälfte.


Die 1517 (wie auch die 1518) zeigen ein ganz anderes verhalten. Die Zykluszeit wird nicht wirklich beeinflusst. ich kann da OPC objekte abonnieren bis zum geht nicht mehr die Belastung steigt nicht so wie ich es erwarte. je tausend abonnierte DINT steigt die Belastung um 3%


Eigentlich müsste man doch durch die Belastung der Kommunikation unabhängig von der CPU Leistung die Zyklusbelastung auf die 50% hochjagen können. Bzw wenn da ein PC ständig anfragt und OPC abonniert hat, müsste es doch auf 50% gehen um die Abonnierten Tags so schnell wie möglich zu aktualisieren? Das passiert aber irgendwie nicht.

Für mich verhalten sich die 1610 bis 1516 anderst als die 1517 und 1518. Bis zur 1516 kann ich den Zyklus auf die 50% belasten, die höheren CPUs dann nicht mehr.

 

[DeltaMikeAir]

Für mich verhalten sich die 1610 bis 1516 anderst als die 1517 und 1518. Bis zur 1516 kann ich den Zyklus auf die 50% belasten, die höheren CPUs dann nicht mehr.

Interessant. Welche FW ist denn auf deinen Versuchs-CPU´s? Da gibt es ja auch noch Performance-Unterschiede bei älteren FW-Ständen.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interessant. Welche FW ist denn auf deinen Versuchs-CPU´s? Da gibt es ja auch noch Performance-Unterschiede bei älteren FW-Ständen.

Beide haben FW 2.8.3 drauf.

 

[Raijin Tycho]

Mein eigentliches Problem ist, dass ich keine reale Hardware habe, sondern nur anhand der vorgesehenen Peripherie-Geräte und Funktionen eine Steuerung auswählen muss. Das nette Tia-Selektion Tool ist dabei nur bedingt hilfreich und soweit ich das beurteilen kann, kann ich die Kommunikationslast unter TIA auch nicht wirklich simulieren.

Vorgesehen ist eine ET200SP-F zu verwenden. Dazu kommen noch 5x S210-Servos, ein nicht näher definierter Servo, ein HMI und eine PLC 1507S als Profinet I-Device, welche alle über Profinet angeschlossen werden. Dazu soll es die Option geben die ET200SP-F an eine übergeordnete Steuerung zu schließen.

Ich könnte jetzt natürlich sagen, dass eine 1510SP / 1512SP das an sich packt und sobald die Kommunikationslast halt >25% ist, hat man halt pech gehabt, aber dieser Ansatz gefällt mir nicht. Auf der anderen Seite wirkt eine 1515SP einfach komplett überzogen.

 

[vollmi]

Ich könnte jetzt natürlich sagen, dass eine 1510SP / 1512SP das an sich packt und sobald die Kommunikationslast halt >25% ist, hat man halt pech gehabt, aber dieser Ansatz gefällt mir nicht. Auf der anderen Seite wirkt eine 1515SP einfach komplett überzogen.

Du könntest die Kommunikationslast auch einfach auf 20% Zykluszeiterhöhung begrenzen. Die frage ist ja nun nicht nur was macht die Kommunikation mit deiner Zykluszeit, sondern auch. Weisst du wie hoch deine Zykluszeit mit der Ausstattung ist und wie hoch sie werden darf? Ueblicherweise ist das überdimensionieren der CPU billiger als nachher aus dem Programm das letzte micron der Sekunde rauszuquetschen.

 

[Raijin Tycho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du könntest die Kommunikationslast auch einfach auf 20% Zykluszeiterhöhung begrenzen. Die frage ist ja nun nicht nur was macht die Kommunikation mit deiner Zykluszeit, sondern auch. Weisst du wie hoch deine Zykluszeit mit der Ausstattung ist und wie hoch sie werden darf? Ueblicherweise ist das überdimensionieren der CPU billiger als nachher aus dem Programm das letzte micron der Sekunde rauszuquetschen.

Das ist genau der Punkt, ich habe keine Ahnung. Ich werde das ganze noch nicht mal selber programmieren. Das soll ein Dienstleister erledigen. Der Dienstleister hat nur gesagt, dass er für das Projekt eine ET200SP haben möchte, aber jetzt soll ich den ganzen Rest bestimmen und damit tue ich mich hat gerade schwer.
Prinzipiell sollte die kleine CPU ausreichend sein, da die ganzen Servos, nie gleichzeitig aktiv sein werden und auch ansonsten die Anforderungen an das Programm nicht groß sind. Aber gerade in hinblick auf zukünftige Projekte wäre es halt interessant gewesen, ob es eine Methode gibt, sowas ganauer zu bestimmen.

 

[PN/DP]

Prinzipiell sollte die kleine CPU ausreichend sein, da die ganzen Servos, nie gleichzeitig aktiv sein werden

Rechnet denn das Programm mehr, wenn ein Servo sich bewegt, als wenn alle Servos stehen? Das ist auch nicht so gut - man muß auch auf relativ gleich lange bzw. gleich kurze Zyklen achten, sonst kann es passieren, daß z.B. bei einer Positionierung an einer Lichtschranke das Objekt ein paar mm später stoppt wenn ein irgendein Servo fährt, gegenüber der Stopposition wenn kein Servo fährt. Die nächste Falle: Werden die Servo-Berechnungen gegeneinander verriegelt, so daß garantiert nie mehr als eine bestimmte Anzahl Servos fährt und aufwendigere Berechnungen durchführt? Nicht das doch mal 2 Servos mehr als üblich fahren und womöglich macht genau dann auch noch jemand einen Seitenwechsel auf der Visu und dann geht die SPS in STOP wegen Zykluszeitüberschreitung. So eng gestrickt darf man die CPU und die Zyklen auch nicht auslegen.

Harald

 

[Raijin Tycho]

Rechnet denn das Programm mehr, wenn ein Servo sich bewegt, als wenn alle Servos stehen?

Hätte ich jetzt angenommen, da das Programm die Funktionen mit Bezug auf den/die Servos nicht aufrufen und abarbeiten muss.

Das ist auch nicht so gut - man muß auch auf relativ gleich lange bzw. gleich kurze Zyklen achten, sonst kann es passieren, daß z.B. bei einer Positionierung an einer Lichtschranke das Objekt ein paar mm später stoppt wenn ein irgendein Servo fährt, gegenüber der Stopposition wenn kein Servo fährt. Die nächste Falle: Werden die Servo-Berechnungen gegeneinander verriegelt, so daß garantiert nie mehr als eine bestimmte Anzahl Servos fährt und aufwendigere Berechnungen durchführt? Nicht das doch mal 2 Servos mehr als üblich fahren und womöglich macht genau dann auch noch jemand einen Seitenwechsel auf der Visu und dann geht die SPS in STOP wegen Zykluszeitüberschreitung. So eng gestrickt darf man die CPU und die Zyklen auch nicht auslegen.

Harald

Sowas ist halt der Grund, warum ich mich damit auseinandersetze und versuche mich da einzuarbeiten. Sowas wie das Tia-Selection Tool ist ja ganz nett, und wenn es mir sagt das für die Motion-Controll 44% der Rechenzeit genutzt wird und 2% für Failsafe, ist das schonmal ein guter Anfang. Aber mit 25% Kommunikationsauslastung kann ich halt wenig anfangen, da ich nicht einschätzen kann,ob so ein Wert für mich reicht.

Wenn ich aber von 25% ausgehe, dann sollte die 1512 das eigentlich packen. Ab 30% oder mehr, müsste ich auf die 1515 gehen.

Als randnotiz: Ich finde, Siemens könnte ruhig noch ne Zwischenstufe zwischen 1512 und 1515 anbieten. Die 1515 wirkt auf mich wie Overkill für meine Anwendung.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Als randnotiz: Ich finde, Siemens könnte ruhig noch ne Zwischenstufe zwischen 1512 und 1515 anbieten. Die 1515 wirkt auf mich wie Overkill für meine Anwendung.

Mit 1515 meinst Du hier an der Stelle ne 1515SP PC Open Controller? Das ist quasi nen Windows Rechner mit ner Soft-SPS in nem Gehäuse was so ähnlich aussieht wie ne 1512SP. Das kannst so wirklich garnicht vergleichen. Und Euer externer Dienstleister wird über das Teil sicherlich garnicht erfreut sein

Also wenn ne 1512SP nicht reicht, würd ich auf ne normele S7-1513-1 PN oder S7-1515-2 PN zurückgreifen. Hängt sicherlich auch noch von den benötigten Schnittstellen ab.

Und da Du oben noch den F-Teil erwähnt hast, in Deinen CPU-Typen find ich garkein F?

Und was ist mit dem Motion Control? Meinst/Brauchst Du etwa na Technologie CPU?

Also ich glaub hier reden alle aneinander vorbei... Und was ist jetzt mit OPC geplant? Am Anfang schreibst Du von 1000 OPC Variablen und am Ende ist davon nichts mehr zu lesen

Also schreib mal detailiert, was Deine CPU alles können muss, wie kurz die Zykluszeit sein muss, wieviel Du kommunizieren musst. Dan krigst hier vielleicht ne Empfehlung, welche CPU passen könnte.

Gruß.

PS: sorry, das mit dem OPC war Vollmi, hat mich verwirrt. Aber Grundsätzlich kannst Du die Kommunikation nur darüber abschätzen indem Du herausfindest, wieviel Du mit wem überhaupt kommunizieren musst...

 

[Raijin Tycho]

Und was ist jetzt mit OPC geplant? Am Anfang schreibst Du von 1000 OPC Variablen und am Ende ist davon nichts mehr zu lesen

Also schreib mal detailiert, was Deine CPU alles können muss, wie kurz die Zykluszeit sein muss, wieviel Du kommunizieren musst. Dan krigst hier vielleicht ne Empfehlung, welche CPU passen könnte.

Gruß.

Die CPU muss eine F-CPU sein, da sie auch für Sicherheitselemente wie NOT-Aus zuständig ist.

Sie muss in der Lage sein 4 Achsen (S210) im Gleichlauf zu verfahren und festzuklemmen. Damit wird die Höhe eines Tische geändert. Die 5te S210 ist eine Drehzahlachse welches ein Schott öffnet und schließt. Max. Verfahrensdauer soll hier 0.5 sec. sein.
Der letzte Servo steuert einen Rundtisch und besitzt einen eigenen Controller welcher über Profinet mit der CPU verbunden wird. Im Grunde erhält der Tisch ein Signal und dreht dann um X° weiter.

Ebenso wird das angesprochene HMI angeschlossen.

Die Steuerung soll autark funktionieren. Aber es soll ebenso die Möglichkeit geben, das Gerät (im Betrieb) an eine übergeordnete Steuerung anzuschließen (über Profinet) und mit dieser zu kommunizieren.

Max. Zykluszeit wurde meines Wissens nach nicht weiter definiert.

 

[ducati]

Puh, ich würd das mal mit dem externen Programmierer besprechen.

Bei "einfachem" Programmierstil würd ich ja mal sagen, es ist nicht soviel. Kommunikation sollte sicherlich nicht das Problem sein, hört sich nach nicht so viel an. Aber ich hab halt von dem Motion Control keine Ahnung. Ne T-CPU solls ja scheinbar nicht werden, die gibts ja als 1512SP garnicht???

Gruß

 

[Jinto]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für mich verhalten sich die 1610 bis 1516 anderst als die 1517 und 1518. Bis zur 1516 kann ich den Zyklus auf die 50% belasten, die höheren CPUs dann nicht mehr.

Ich tippe mal darauf, dass 1517/1518 Multi-Core CPUs sind. Dann könnte man das unter der Annahme, dass Kommunikation und WebServer (etc. pp.) parallel arbeiten schon erklären.