TIA CPU Upgrade sinnvoll?

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi

aktuell haben wir an einer Anlage eine 1512SP F-1 PN CPU im Einsatz, welche aufgrund von verschiedener Erweiterungen und Änderungen mittlerweile eine durchschnittliche Zykluszeit von fast 20ms aufweist. Eine Überlegung ist, zumindest bei einer nachfolgenden gleichen Anlage, die CPU upzugraden. Das nächst bessere Modell welches in Betracht käme wäre eine 1515F-2 PN CPU (vereinfacht gesagt ca 30-40% leistungsfähiger). Programmspeicher, fehlende Features usw sind nicht das Problem.
Allerdings müsste dann die Kommunikation mit der Peripherie zwingend über PN zu einem ET200SP-Interface erfolgen und nicht direkt über den Rückwandbus, was hier dann wohl grob gesagt eine Latenz von ca 2ms (zumindest ohne weitere Verschärfung der Kommunikationsparameter und Einsatz von PN-RT usw) verursachen würde.
Allerdings ist es an der Anlage nicht so, dass diese in irgendeiner Weise in "Echtzeit" reagieren müsste. Weder Produktions-, noch Sicherheitstechnisch. Ein paar wenige Eingänge welche kurze Impulse erfassen müssen werden sowieso mit speziellen Eingangsmodulen ausgewertet und nicht direkt über den CPU Zyklus.
20ms ist jetzt nicht gut aber auch nicht die Welt, da gibt es sicher schlimmeres, jedoch möchte man natürlich Dinge verbessern und auch für die Zukunft leistungsfähig bleiben. Aber würde das hier überhaupt Sinn machen? Ja, die Zykluszeit wäre natürlich besser, aber ohne großen Mehrwert. Sehe ich das richtig?

 

[JesperMP]

Anstatt ein 1515F-2, dann vielleicht ein 1515SP Open Controller.
Diese CPU verbindet sich direkt zu die ET200SP Modulen, ohne PN IM.
Ein 1515SP ist mindestens 10-fach schneller als ein 1512. Ist vergleichbar zu ein 1516.
Nachteil ist das es dauert wesentlich länger als als ein "echte" CPU um zu starten.

 

[Fluffi]

Zuviel Werbung?
-> Hier kostenlos registrieren

1515SP Open Controller gefällt mir gut, würde hier aber nicht in das Konzept passen, auch wenn sie recht schnell ist.
Würdet ihr bei 20ms Zykluszeit was ändern, nur um dann am Ende 12ms dastehen zu haben, ohne dass aber schlußendlich ein echter Mehrwert dabei rauskommt?

 

[rostiger Nagel]

1515SP Open Controller gefällt mir gut, würde hier aber nicht in das Konzept passen, auch wenn sie recht schnell ist.
Würdet ihr bei 20ms Zykluszeit was ändern, nur um dann am Ende 12ms dastehen zu haben, ohne dass aber schlußendlich ein echter Mehrwert dabei rauskommt?

ich denke das du du nur duch die Mindestzykluszeit überhaupt über 1ms kommst,
Zykluszeit war doch dein Thema?
Bei den Soft-SPSen wird die Zykluszeit in µs gemessen, weil Sie ein wenig schneller
sind als eine Hard SPS und da gibt es noch einige andere Vorteile.

 

[ducati]

Würdet ihr bei 20ms Zykluszeit was ändern, nur um dann am Ende 12ms dastehen zu haben, ohne dass aber schlußendlich ein echter Mehrwert dabei rauskommt?

20ms ist jetzt nicht gut aber auch nicht die Welt, da gibt es sicher schlimmeres, jedoch möchte man natürlich Dinge verbessern und auch für die Zukunft leistungsfähig bleiben. Aber würde das hier überhaupt Sinn machen? Ja, die Zykluszeit wäre natürlich besser, aber ohne großen Mehrwert. Sehe ich das richtig?

Naja, Du musst halt überlegen, was Du mit der Steuerung steuerst und welche Zykluszeit (Reaktionszeit) Du zwingend benötigst... Bei verfahrenstechnischen Anlagen hat man manchmal ne OB1 Zykluszeit von 500ms... Das stört niemanden. Nebenbei kannst Du zeitkritische Programmteile ja auch in einen schnelleren Weckalarm auslagern...

Also m.M. nach sehe ich jetzt keinen Grund bei Dir, warum Du wechseln solltest. Die 1515 hat halt eher den Vorteil einer 2. Schnittstelle... Und natürlich mehr Speicher, was dann manchmal notwendig ist.

Zur F-Geschichte bzw. zykluszeit fürs Sicherheitsprogramm wurde ja noch nichts gesagt, das wäre vielleicht nen Punkt.

Gruß.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja, Du musst halt überlegen, was Du mit der Steuerung steuerst und welche Zykluszeit (Reaktionszeit) Du zwingend benötigst

Das ist eigentlich die entscheidende Frage. Z.b. bei unseren Kistentransportanlagen ist es nicht relevant, ob 20ms, 30ms oder 100ms.
Bei einem schnellen Palettierer schon eher....

 

[Kabeläffle]

Hallo Fluffi,

wenn du die Automatisierung für ein Kieswerk machst, dann spielt die Zykluszeit vermutlich eine sehr untergeordnete Rolle. Wenn du hier eine etwas größere CPU verwendest, dann in der Regel wegen dem größeren Adressbereich, oder dem Komfort bei Änderungen/Umbauten.

Baust du allerdings Fertigungsmaschinen, welche Teile in verhältnismäßig kleinen Taktzeiten herstellt, dann sind schnelle Steuerungen elementar wichtig.

Beispielrechnung: Artikel auf langsamer Steuerung kann in 5s durch die Maschine hergestellt werden. Die CPU hat eine Zykluszeit von 20ms. Es finden für einen Maschinentakt 25 Bewegungen statt.

Reaktionszeiten der langsamen CPU pro Artikel = 20ms * 25 * 2 = 1000ms
Reaktionszeit der schnellen CPU pro Artikel = 1ms * 25 * 2 = 50ms

Deine Taktzeit könnte von 5s auf 4,05s sinken!

Gruß
Kabeläffle

 

[Stoky]

Also wir setzen die gleiche Steuerung (1512) ein und ringen mit einer ähnlichen Überlegung. Allerding ist bei uns der OB1 Zyklus ca. bei 2ms. Problematischer ist da schon das Sicherheitsprogramm was so bei 8-9ms rumkriecht. Vielleicht ist das bei euch ja auch problematisch.

Bei meinem alten Arbeitgeber hatten wir Maschinen die mit Schrittketten liefen, da war wie Kabeläffle schon schrieb die Zykluszeit sehr relevant. Man spart zwar nicht so viel Zeit wie er schreibt, da das nur im theoretischen worst case Fall auftreten würde, aber der Unterschied ist schon enorm. Wir haben damals unser programm analysiert und verschiedene "Übeltäter" ermittelt die die Zykluszeit hochschrauben. Wir haben dann unkritische Programmteile nicht mehr jeden Zyklus, sondern abwechselnd aufgerufen. das hat bei uns damals ca. 35% Ersparnis gebracht (17 statt 27ms) und unsere Maschine fuhr danach statt 8,1s mit 7,95. Da 8s Bedingung war wurde somit das Ziel erreicht. Vielleicht ja auch eine Option für euch.

 

[Kabeläffle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man spart zwar nicht so viel Zeit wie er schreibt, da das nur im theoretischen worst case Fall auftreten würde, aber der Unterschied ist schon enorm. Wir haben damals unser programm analysiert und verschiedene "Übeltäter" ermittelt die die Zykluszeit hochschrauben. Wir haben dann unkritische Programmteile nicht mehr jeden Zyklus, sondern abwechselnd aufgerufen. das hat bei uns damals ca. 35% Ersparnis gebracht (17 statt 27ms) und unsere Maschine fuhr danach statt 8,1s mit 7,95. Da 8s Bedingung war wurde somit das Ziel erreicht. Vielleicht ja auch eine Option für euch.

Von wegen „Man spart zwar nicht so viel Zeit“. Durch das EVA-Prinzip geht die CPU-Zyklus-Zeit 2-fach in die Rechnung ein. Dann wirkt sich eine 20-fach schnellere Steuerung 40-fach aus!
Bei Serienmaschinen kann es sich lohnen das Programm zu „optimieren“, im Sondermaschinenbau wird das aber ganz schnell fragwürdig…

 

[Stoky]

Bei Serienmaschinen kann es sich lohnen das Programm zu „optimieren“, im Sondermaschinenbau wird das aber ganz schnell fragwürdig…

Also ich arbeite auch im Sondermaschinenbau. Trotzdem haben die meisten Firmen Vorlageprojekte oder Projektgrundlagen die dann bei allen Maschinen gleich sind. Da würde ich ansetzen.

Reaktionszeiten der langsamen CPU pro Artikel = 20ms * 25 * 2 = 1000ms
Reaktionszeit der schnellen CPU pro Artikel = 1ms * 25 * 2 = 50ms

[...]

Von wegen „Man spart zwar nicht so viel Zeit“. Durch das EVA-Prinzip geht die CPU-Zyklus-Zeit 2-fach in die Rechnung ein. Dann wirkt sich eine 20-fach schnellere Steuerung 40-fach aus!

Ich meinte damit, dass 20% in den meisten Fällen unrealistisch sind, aber da ist ja jede Maschine anders.

Trotzdem ist die zweifache Zeit so nicht ganz korrekt:

1. Die zweifache Zeit (Verzögerung beim einlesen und dann beim Schreiben) tritt nur im Worst Case Fall auf. Im Best Case Fall ist der Unterschied die einfache Zeit (Ereignis ist direkt vor dem Einlesen der langsamen Steuerung gekommen, der abgefragte Zustand ist also nicht schon fast einen Zyklus alt.) --> Der Mittelwert wäre Faktor 1,5.

2. Bei steuerungsinternen Ereignissen bei denen nicht auf ein eingelesenes Signal reagiert wird ist der Worst Case ein Zyklus und im Best Case gar kein Unterschied --> Mittelwert wäre Faktor 0,5.

Dadurch kann man nicht genau sagen mit welchem Faktor das in die Rechnung eingeht.

 

[JesperMP]

2. Bei steuerungsinternen Ereignissen bei denen nicht auf ein eingelesenes Signal reagiert wird ist der Worst Case ein Zyklus und im Best Case gar kein Unterschied --> Mittelwert wäre Faktor 0,5.

Genau.
Obwohl den Gewinn ist nicht ein Faktor 2.0 sondern nur 0.5, wäre es uU. absolut wert eine Leistungsfähiger CPU zu wählen, nur um ein kleinen Zykluszeitverringerung zu bekommen.
Z.B. wenn man durch von ein Investition von 1000 € eine Produktionserhöhung von 2% bekommt über den Lebensdauer von den Maschine, dann wäre es das absolut wert.

 

[Stoky]

Zuviel Werbung?
-> Hier kostenlos registrieren

Z.B. wenn man durch von ein Investition von 1000 € eine Produktionserhöhung von 2% bekommt über den Lebensdauer von den Maschine, dann wäre es das absolut wert.

Als Betreiber der Maschine ist das sicherlich richtig. Als Erbauer macht man nur so viel wie vertraglich zugesichert. Wenn die kleine Steuerung reicht um den Vertrag einzuhalten wird diese genommen um Kosten zu sparen.

 

[Chräshe]

Als Betreiber der Maschine ist das sicherlich richtig. Als Erbauer macht man nur so viel wie vertraglich zugesichert. Wenn die kleine Steuerung reicht um den Vertrag einzuhalten wird diese genommen um Kosten zu sparen.

Und wenn der arme Programmierer für die „Zyklus-Zeit-Optimierung“ 6 Tage länger auf der Baustelle ist, bei dem Versuch 3 x Schrott fährt, nur um die „billige“ CPU weiter nutzen zu können, dann nennt man das Milchmädchenrechnung…

 

[JesperMP]

Als Betreiber der Maschine ist das sicherlich richtig. Als Erbauer macht man nur so viel wie vertraglich zugesichert. Wenn die kleine Steuerung reicht um den Vertrag einzuhalten wird diese genommen um Kosten zu sparen.

Anzahl produzierte Teile pro Stunde muss im Vertrag stehen. Wenn Hersteller A 1000 Teile pro Stunde anbietet, und Hersteller B 1010 Teile pro Stunde anbietet für 1000 € mehr, dann bekommt Hersteller B den Vertrag.

 

[Stoky]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wenn der arme Programmierer für die „Zyklus-Zeit-Optimierung“ 6 Tage länger auf der Baustelle ist, bei dem Versuch 3 x Schrott fährt, nur um die „billige“ CPU weiter nutzen zu können, dann nennt man das Milchmädchenrechnung…

An der Stelle wurde da vermutlich eher am Programmierer gespart, wenn der bei so ner Aktion nen Crash fährt. Aber klar, auch das wäre dann auch eine Milchmädchenrechnung. Natürlich ist es Schwachsinn da tagelang hinzufahren um zu optimieren. Entweder man macht das in einem Abwasch für alle Maschinen vor der Inbetriebnahmephase oder man nimmt die größere CPU.

Anzahl produzierte Teile pro Stunde muss im Vertrag stehen. Wenn Hersteller A 1000 Teile pro Stunde anbietet, und Hersteller B 1010 Teile pro Stunde anbietet für 1000 € mehr, dann bekommt Hersteller B den Vertrag.

Ja klar, Hersteller B wird dann aber auch nur 1010 liefern und nicht 1200. Er wird höchstens versuchen die 1200 teuer zu verkaufen.

 

[Fluffi]

Also, an der Maschine laufen mehrere Stationen parallel ab, und die langsamste Station ist aufgrund des mechanischen Vorganges nicht die schnellste und es muss sowieso viel gewartet werden.
Was das Safety-Programm angeht: Das wird ja erstens unabhängig vom OB1 Zyklus aufgerufen, hier sind es denke ich 50ms, und die Bearbeitungszeit des Safety-Programms selber ist sehr gering und muss auch aufgrund der Sicherhheitsrealisierung nicht in harter Echtzeit sein.

Je mehr ich drüber nachdenke, desto weniger Sinn, außer einem guten Gefühl macht es eigentlich. Vor allem wenn man bedenkt, dass die CPUs welche in Betracht kämen über PN an die Module angebunden werden müsste, was ja nochmals Zeit kostet. Aus der ET200SP Reihe gibt es ja nichts leistungsfähigeres.

Die Berechnung vom Kabeläffle ist sicher mathematisch richtig, aber würde sich an den meisten realen Maschinen so direkt nicht auswirken. Es gibt immer Überschneidungen und parallele Vorgänge.

 

[Kabeläffle]

Die Berechnung vom Kabeläffle ist sicher mathematisch richtig, aber würde sich an den meisten realen Maschinen so direkt nicht auswirken. Es gibt immer Überschneidungen und parallele Vorgänge.

Klar, parallele Arbeitsgänge entschärfen meine Rechnung.

Wenn du aber ein Handshake mit einer 2. Steuerung hast (Roboter, Datenbank,…), dann kannst du deren Reaktionszeiten nochmals dazuzählen.

Die Relevanz der Zykluszeit ist sehr abhängig von der Anwendung. Daher mein Beispiel mit dem Kieswerk. Antriebe für mehrere Stunden in einer bestimmten Anlaufkette anlaufen lassen, könnte auch mit einer Zykluszeit von 500ms problemlos funktionieren, ohne dass sich das Produktiv auswirkt.