Step 7 Anlage schneller machen

achimE

Level-1
Beiträge
8
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

ich habe die Aufgabe eine Anlage mit CPU 318-2 V1.1 schneller zu machen. Also mehr Stückzahl. Die Zykluszeit beträgt 15ms. Ich denke durch eine schneller CPU könnte das klappen.

Jetzt die Frage: Bringt es was eine CPU 318-2 V3.0 einzubauen? Ich finde zwar zu der 318-2 eine Übersicht mit den Zeiten für die Befehle, aber nicht für die V1.1. Die ominöse Einheit ms/kAW ist laut Hardwaremanager bei der V1.1 0,3ms/KAW und bei der V3.0 0,1ms/KAW.

Gibt es sonst noch Tricks & Tipps was ich machen könnte.
z.B. Größe des Eingangs- Ausgangsbereichs?
Teile des Programms ind OB35 auslagern und nur alle ca. 30ms aufrufen?


Bin für jeden Tipp dankbar.

Gruß
achim
 
Wenn die 'Anlage' eine wirkliche Anlage ist, würd ich doch mal den Prozess anschauen und versuchen daran zu schrauben, was bringt eine Zykluszeit von 1ms, wenn der Zylinder 3 Stunden braucht um die Endlage zu erreichen....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Davon mal ab, eine 318 ist schwer zu bekommen, die gibt es schon eine ganze weile nicht mehr.

Wenn du aus der CPU etwas herausholen möchtest geht vielleicht eine 319 oder besser gleich
eine Leistungsstarke 1500er.
 
Ich finde eine Zykluszeit von 15 ms gar nicht so schlecht.
Soll es viel schneller werden würde eine stärkere CPU schon helfen. CPU 317 -> CPU 319 bringt da schon ganz schön etwas. ABER : nur bei der Zykluszeit. Die Anlage selbst wird dadurch nicht schneller werden (siehe Beitrag von Manfred Stangl) außer vielleicht hier und da ein paar Millisekunden, weil eine Reaktion vielleicht tatsächlich ein ganz klein bißchen schneller stattfindet.
Wo du auf diese Weise allerdings echte Zuwächse erhältst ist die Beschleunigung von Berechnungen (hier vor Allem Schleifen-Berechnungen).

Vielleicht schreibst du doch mal etwas mehr zu deinem Vorhaben ...

Gruß
Larry
 
Naja, wie schon geschrieben, brauchen wir hier mehr Infos (was ist das für eine Anlage?). Dass die Stückzahl der Anlage deutlich steigt, nur weil Du die Zykluszeit der SPS verringerst halte ich auch erstmal für ein Gerücht. Von 318 auf 319 umzurüsten würde ich auch mit Vorsicht genießen, da die 318 eigentlich eine 400er ist, und somit mehr oder weniger aufwändige Programmänderungen von Nöten sein könnten.

Also ich würde mir die Anlage erstmal genau anschauen, wo eigentlich die Engpässe liegen. Unabhängig von der Mechanik würd ich im Programm mal nach Schrittketten und Timern Ausschau halten. U.U. kann man da was optimieren.

Gruß.

PS: dass mit den Weckalarmen funktioniert auch nicht ganz so einfach. (Wenn Du nur die langsamen Programmteile in nen OB35 auslagerst, wird der OB1 zwar oft schneller, aber alle x Zyklen ist er aber genauso lang wie vorher, da der OB1 durch OB35 unterbrochen wird). Da müsste man dann schon das ganze Programm sinnvoll in verschiedene Weckalarme aufteilen und u.U. noch mit Teilprozessabbildern arbeiten.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibt es sonst noch Tricks & Tipps was ich machen könnte.
z.B. Größe des Eingangs- Ausgangsbereichs?
Teile des Programms ind OB35 auslagern und nur alle ca. 30ms aufrufen?

Das ist äusserst schwer zu sagen wenn man nicht weiss was die CPU so zu tun hat.
Ist die Zykluszeit denn stabil?

Dazu hat Manfred ja auch noch das Argument der Peripherie gebracht die muss natürlich entsprechend schnell reagieren.
Ausserdem kommt es dann noch dazu drauf an was für eine IO Hardware du verwendest. Wenn du Analogkarten oder IO Karten mit langsamer Wandlungszeit drin hast schlägt das ebenfalls in die Reaktionszeit.

Du kannst du deine Software in einen schnellen Weckalarm legen, nützt dir aber nur was wenn die Daten dann auch entsprechend schnell kommen. Sortieralgorithmen die du nicht Zyklusgenau brauchst lässt du im OB1 das beschleunigt dann schon etwas.

Wenn du jetzt eine 300er gegen eine schnellere 300 ersetzt dann wird das schon Auswirkung auf die Geschwindigkeit haben, wie viel liegt aber wieder stark am Programm. Und zu bedenken ist, du ersetzt dann alte Hardware gegen schnellere alte Hardware.

Da würde ich dann eher gegen ne 400er tendieren (die 400er wirds länger geben als die 300er)
Bei der 400er kannst du dann auch nur die relevanten Prozessabbilder aktualisieren je nach Weckalarm, was gerade bei grösseren Anlagen einen enormen Schub bringt. Und wenns dann immernoch nicht reicht mehrere CPUs zusammenhängen (Multicomputing) dann wird deine Peripherie schmelzen.

Und dann gibts da noch die schnellen 1500er da ist dann wieder Luft nach oben. Da hab ich aber noch nicht so richtig Zeitkritische Sachen mit gemacht.


mfG René
 
Zuletzt bearbeitet:
Dann möchte ich mal unserern Flaschenhals genauer beschreiben.

Ein Roboter entnimmt von einem Werkstückträger vier Produkte und legt sie in eine Haltevorreichtung ein. Dort werden je Produkt 2 Kleinteile angeschweißt und danach wieder auf den WT abgelegt. Die Zuführung der Kleinteile ist relativ aufwendig, allerdings nicht zeitkritisch. Die Verbindung zwischen SPS und Schweißsteuerung erfolgt über serielle Schnittstelle. Das Zeitproblem ist das Handling der Produkte durch den Roboter und das Schweißen (Roboterschrittkette). Die Produkte müssen in der Haltevorrichtung durch den Roboter gedreht werden.

Die Taktzeit je Produkt beträgt ca. 5.1 sec. Das Ziel wären ca. 4.7 sec. Da immer 4 Teile entnommen werden beträgt ein Takt aktuell 20.4 sec und soll auf min. 18,8 sec reduziert werden.

Bisher habe ich folgendes gemacht.
1.) Den Ablauf gefilmt und analysiert welche Schritte paralell gemacht werden können. Hier sind mir auch die ein oder anderen Kleinigkeiten aufgefallen.
2.) Prozess (also das Schweißen) analysiert. Da Kunststoffteile verschweißt werden ist das Schweißen sehr kurz. Die Ruhe, bzw. Abkühlzeit konnte noch reduziert werden.
3.) Bin gerade dabei die Schnittstelle zwischen Robi und SPS zu durchforsten, ob da was optimiert werden könnte.
4.) Zylinder sind alle schon optimal eingestellt
5.) Geschwindigkeit des Roboters schon recht hoch

Bei den Anlagen die ich bisher optimiert habe, bin ich damit auch immer ganz gut hingekommen:
  • Also der Hauptpunkt ist zu versuchen Schritte parallel anstatt in Reihe auszuführen.
  • Die Positionierfenster der Umrichter auf realistische Werte anzupassen 1/10 mm anstatt 1/1000mm
  • Wartezeiten/Timer im Programm zu finden und zu reduzieren
  • Schon mit dem Lesen der Datenträger am WT den Greifer auf das Werkstück fahren lassen und nicht erst nach dem Lesen

Hier fehlen mir jetzt noch für 4 Teile ca. 700ms und deswgen die Idee mit der schnelleren Steuerung oder alternativ mit einer Möglichkeit die Zykluszeit zu drücken. Also ich glaub ich muss mich meinem Ziel mit 50ms Schritten näheren.

Die Zykluszeit ist stabil. Keine Analogen Ein- und Ausgänge sonderen alles nur binäe Ein- und Ausgänge, bis auf die serielle Schnittstelle.

Gruss

Achim
 
Zuletzt bearbeitet:
Ich möchte mal behaupten das eine schnellere CPU nichts bringt. Deine anderen Ideen sollten für die ein oder andere ms gut sein.
 
Kleiner Tipp..

Wenn du mit Graf-Schrittketten arbeitest, dann schalte in allen Schrittketten die Option "Transitionen permanent" bearbeiten aus.
Wenn ich das richtig in Erinnerung habe, könnte das bei einer aktuellen 315 etwa 250ms bringen (bei 20s Taktzeit und 5 abzuarbeitenden Stationen, welche der Roboter anfahren musste (?))
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Auch einmal schauen in welcher Art die Kette laufen!
Nicht das jede Kette seine eigen Betriebsart hat, da gibts doch die Möglichkeit alle Ketten mit einer BA und dadurch kleinere DB's zu betreiben.
Bringt auch Zeit! Auch die schnellere CPU wird etwas bringen ... Es sind halt alle Einzel Optionen welche das gesamte bringen ...

Bei Robis habe ich meist festgestellt, das man da anhand deren Programmierung einiges optimieren kann!
Gerade im Bereich Aufruf, Job Verwaltung und Start ...
 
Zurück
Oben