Step 7 Geschwindigkeit 1500er

SPS_NEU · 12 Juni 2017

Hallo Gemeinde,

in habe mal eine theoretische Frage:

Bisher betreibe ich eine bestehende Lageregelung mit einer ET200s. Geregelt wird ein hydraulischer Zylinder, der sich mit einer Frequenz von 25hz sinusförmig bewegt. Der Zylinder und das zugehörige Ventil sind für die Geschwindigkeit ausgelegt.
Mein Problem ist die Geschwindigkeit der CPU. Die Lageregleung und die sinusförmige Sollwertberechnung wird im OB35 mit 2ms betrieben. Leider kommt die Regelung bei dieser Frequenz manchmal an die Grenzen. Die Wegmessung bzw. Ventilsteuerung wird über Highspeedkarten 4..20mA umgesetzt.

Jetzt zu meiner Frage: Gibt es Sterungen (evtl. 1500er) die eine deutlich schneller Zykluszeit bieten?

Danke schon mal für euere Gedanken....

JesperMP · 12 Juni 2017

Du meinst vermutlich ein IM151-8. Dies ist vergliechbar zu ein S7-314.
Oder meinst du ein IM151-7 ? Dies ist wesentlich langsahmer als IM151-8.
Du kannst den IM151-8 CPU für ein schnellere CPU austauschen, wie ein S7-317. Den E/A muss dann über ein Profinet IM betrieben werden.

Aber vielleicht gibt es auch den Möglichkeit den Code in OB35 zu optimieren. Eigentlich sollte ein Zykluszeit von 2 ms machbar sein, selbst für ein IM151-8.

weißnix_ · 12 Juni 2017

Sollwerte für die Bewegung könnten mglw. als Tabelle vorberechnet werden.

SPS_NEU · 12 Juni 2017

Ist die sollwertvorgabe als feste Werte schneller als über eine sinuskurvenberechnung?

SPS_NEU · 12 Juni 2017

Gibt es für die et200s auch regelbaugruppen wie bsp fm355c bei der s7-300?

Blockmove · 12 Juni 2017

SPS_NEU schrieb:
Leider kommt die Regelung bei dieser Frequenz manchmal an die Grenzen.

Wie äussert sich das?
Hydraulische Servoventile haben auch so ihre Eigenheiten (Überdeckung, Unlinearität, Stellzeit)

Gruß
Blockmove

SPS_NEU · 12 Juni 2017

Ungenauigkeit. Fehler von ca. 20%. Und da eine visu über profinet dran hängt, stockt die regelung bei datenübergabe aller 1Sekunden

JesperMP · 12 Juni 2017

SPS_NEU schrieb:
Und da eine visu über profinet dran hängt, stockt die regelung bei datenübergabe aller 1Sekunden

Das ist Quatch. Profinet prioriziert den RT IO über anderen Datenverkehr. Es sei denn, du verwendest nicht-Profinet Switche.

SPS_NEU · 12 Juni 2017

Ich nutze nur den Profinet-Anschluss der CPU direkt zum Visu-Rechner. Kein Switch. Man kann aber genau sehen, dass wenn die Visu die Daten aktualisiert (1sek), dass die Regelung sich verschluckt oder zumindest die Werte nicht korrekt umsetzt.
Nochmal zu der Frage: Gibt es Reglerkarten für die CPU, die die Regelung eigenständig übernehmen?

rostiger Nagel · 12 Juni 2017

Vielleicht mal eine 1200er nutzen und diese
als Regelbaugrupoe an deine ET200s hängen.
Sehr Preiswert und sehr Performant.

SPS_NEU · 12 Juni 2017

naja, die Highspeed AO/AI Karte sitzt an der ET200s. Wie kann dann die 1200er die Regelung übernehmen?

vollmi · 12 Juni 2017

SPS_NEU schrieb:
Ungenauigkeit. Fehler von ca. 20%. Und da eine visu über profinet dran hängt, stockt die regelung bei datenübergabe aller 1Sekunden

Also die Regelung fäng an zu Zicken wenn das Panel zugreift? Aber da Stimmt doch dann was nicht. Wenn du die Regelung in nem Weckalarm abarbeitest kann dieser doch nicht durch Kommunikations unterbrochen verzögert oder whatever werden.
Würde die Kommunikation den Weckalarm verzögern würde ein OB geworfen werden der die Zyklusüberschreitung meldet. Wenn das nicht passiert ist mit deinem Zyklus alles in ordnung und eine schnellere CPU würde überhaupt nix bringen.
Arbeitest du im Weckalarm mit Direktzugriffen oder mit dem Peripheriebereich?

Oder übersehe ich was Fundamentales?

mfG René

rostiger Nagel · 12 Juni 2017

Das du Highspeed Karten verwendest hätte ich überlesen,
brauchst du diese den wirklich?
Vielleicht reicht ja die Geschwindigkeit der Analogen Eingänge und
eines Analogen Ausganges auf der 1200.

ducati · 12 Juni 2017

SPS_NEU schrieb:
Ich nutze nur den Profinet-Anschluss der CPU direkt zum Visu-Rechner. Kein Switch. Man kann aber genau sehen, dass wenn die Visu die Daten aktualisiert (1sek), dass die Regelung sich verschluckt oder zumindest die Werte nicht korrekt umsetzt.

steht da irgendwas im Diagnosepuffer?

Naja, je nachdem was in der HW-Konfig eingestellt ist, könnte durch die Kommunikation mit dem Panel schon die Zykluszeit, evtl. auch die OB35 Zeit sich verlängern.

Probieren könntest Du den Parameter "Zyklusbelastung durch Kommunikation" zu verkleinern...

weiterhin sollte auf der CPU der Webserver deaktiv sein, SFM aus sein... kein unnötig großes Prozessabbild... keine Kommunikation zu Fremdsteuerungen, PG...

aber 2s für den OB35 find ich trotzdem sportlich

ansonsten ne 1512SP-1PN sollte eigentlich je nach Anwendungsfall schon schneller sein. Hat aber den Nachteil, mit dem TIA-Portal projektiert werden zu müssen...

https://mall.industry.siemens.com/mall/de/de/Catalog/Products/10239949?tree=CatalogTree

Gruß.

vollmi · 12 Juni 2017

ducati schrieb:
Naja, je nachdem was in der HW-Konfig eingestellt ist, könnte durch die Kommunikation mit dem Panel schon die Zykluszeit, evtl. auch die OB35 Zeit sich verlängern.

Ich war der Meinung Verschiebungen der Weckalarmzyklen durch Kommunikation wird automatisch Kompensiert und beeinflusst Regelbausteine darin nicht? Solange sie derselbe Weckalarm nicht selber unterbricht.

Kann man der Kommunikation nicht auch eine niedrigere Priorität zuweisen als die Weckalarme?

mfG René

ducati · 12 Juni 2017

vollmi schrieb:
Ich war der Meinung Verschiebungen der Weckalarmzyklen durch Kommunikation wird automatisch Kompensiert und beeinflusst Regelbausteine darin nicht? Solange sie derselbe Weckalarm nicht selber unterbricht.

Kann man der Kommunikation nicht auch eine niedrigere Priorität zuweisen als die Weckalarme?

mfG René

Tja der Siemens schreibt in der Step7 Hilfe folgendes:

Beispiel 2 (zusätzlichen asynchrone Ereignisse berücksichtigt):

Bei einer reinen OB 1-Ablaufzeit von 500 ms kann sich durch eine Kommunikationslast von 50 % eine tatsächliche Zykluszeit von bis zu 1000 ms ergeben (unter der Voraussetzung, daß die CPU immer genügend Kommunikationsaufträge zum Bearbeiten hat). Wenn nun parallel dazu alle 100 ms ein Weckalarm mit 20 ms Bearbeitungszeit abläuft, dann würde sich dieser ohne Kommunikationslast mit insgesamt 5*20 ms = 100 ms auf den Zyklus verlängernd auswirken, d. h. die tatsächliche Zykluszeit wäre 600 ms. Da ein Weckalarm auch die Kommunikation unterbricht, wirkt er sich bei 50% Kommunikationslast mit 10 * 20 ms auf die Zykluszeit aus, d.h. in diesem Fall beträgt die tatsächliche Zykluszeit nicht 1000 ms sondern 1200 ms.

Ob das stimmt, weiss ich nicht

Jedenfalls deshalb meine Frage zum Diagnosepuffer, da sollte bei Problemen mit dem OB35 was drinstehen.

Ich sehe es so wie Du, generell stimmt da was nicht. Vielleicht ist auch im OB1 noch was wichtiges Programmiert. Wenn man mit dem PG an der Steuerung hängt, passiert bestimmt auch einiges komische... Oder im Programm sind viele Sprünge, welche zu irgendwelchen Problemen führen... Man weiss es nicht.

Jedenfalls bedingt diese Anwendung schon einiges an Gehirnschmalz um auf die 2ms dauerhaft ohne Probleme zu kommen.

Blockmove · 12 Juni 2017

Also 2ms sind unbestritten sportlich. Sollten aber machbar sein.
Ich frag mich allerdings, ob 2ms Takt für eine hydraulische Achse notwendig sind.

Die heftige Beeinflussung dur die Panelkommunikation wundert mich auch sehr.
Was passiert, wenn du mit S7-Online den Baustein im Status anschaust?
Da müsste die Probleme eigentlich noch größer werden.
Mein Verdacht ist auch, dass du irgendeine Kopplung der Programmteile im OB35 und OB1 hast.
Also entweder über Prozessabbild oder irgendwelche Berechnungen oder sonstwas.

Gruß
Blockmove

DeltaMikeAir · 12 Juni 2017

Ich frag mich allerdings, ob 2ms Takt für eine hydraulische Achse notwendig sind.

Das hatte ich mich auch schon gefragt. Hat diese Achse nicht eine gewisse Trägheit?

Blockmove · 12 Juni 2017

DeltaMikeAir schrieb:
Das hatte ich mich auch schon gefragt. Hat diese Achse nicht eine gewisse Trägheit?

Es gibt schon hochdynamische hydraulische Antriebe.
Öl ist nicht kompressibel, also kannst du dir die Hydraulik quasi als starres System vorstellen.
Eigentlich nichts anderes als z.B. eine Kugelspindel. Und somit sind auch sehr dynamische Antriebe möglich.
Die Kunst darin liegt so ein System passend auszulegen. Rohrverlegung, Querschnitte, Temperaturen und zig andere Faktiren spielen dabei eine wichtige Rolle.

Gruß
Blockmove

ducati · 12 Juni 2017

Blockmove schrieb:
Mein Verdacht ist auch, dass du irgendeine Kopplung der Programmteile im OB35 und OB1 hast.
Also entweder über Prozessabbild oder irgendwelche Berechnungen oder sonstwas.

Jo, danach sieht es aus... zumindest aus der Glaskugel

Wenn die E/As im OB 35 nicht als PEW/PAW benutzt werden, dann wird bei Kommunikation zwar weiterhin der OB35 alle 2ms aufgerufen, aber die Ein/Ausgänge haben noch den alten Wert bzw. werden nicht ausgegeben...

Gruß.

Step 7 Geschwindigkeit 1500er

Level-2

Level-3

weißnix_

Guest

Level-2

Level-2

Supermoderator und User des Jahres 2019

Level-2

Level-3

Level-2

Forums-Knochenbrecher

Level-2

Level-3

Forums-Knochenbrecher

Level-3

Level-3

Level-3

Supermoderator und User des Jahres 2019

User des Jahres 2018; 2023

Supermoderator und User des Jahres 2019

Level-3

Similar threads

Wir schützen deine Privatsphäre