Zykluszeiten... von Steuerungen

[Speedo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen

Ich bin nicht ein Vielschreiber in Foren, bin eher gerne der sich die Sachen im WWW zusammensucht und dann probiert wie es funktioniern kann.

Jedoch bin ich gerade an einem Punkt der mich zum verzweifeln bringt.

Ich hab in meiner alten Firma 5 Jahre lang mit Beckhoff div. Lagersysteme programmiert.
Nun hab ich die Firma gewechselt und soll nun hier eine neue Maschinen Typ Programmieren der sehr schnell ist.
Wir wollen 330 Stück / Min produzieren dies in 4er Gruppen daher ist die Taktzeit 720ms.
Da wir in einem Tack 5 Bewegungen Überwachen/fahren müssen brauchen wir min 5 Zyklen pro Tackt.

Unsere Steuerung hat eine Zykluszeit von momentan 20ms noch nicht alles in Betrieb genommen.
Wir haben 18 Servoverstärker davon laufen 3 in CAM.
Die Anlage ist Event gesteuert, wir Warten auf eine anzahl Wägelchen und dann starten wir einen Teil vom Prozess.

Ich möchte keine Diskussion auslösen wie oder warum Ihr/wir dies/das machen ich möchte auf die Zykluszeit hinaus.

Hat jemand von euch hochflexible Anlagen programmiert in dieser Geschwindigkeit & Event gesteuert mit mehrer Servoverstärke Zentral in einer SPS?
Wie schnell war da eure Steuerung?
Ich meine einfach 20ms evtl. enden wir bei 30ms sind extrem viel?

Grüsse Simon

 

[Larry Laffer]

Hallo Simon,
grundsätzlich teile ich deine Bedenken. Ich habe schon Vergleichbares programmiert, dabei war dann aber die Taktzeit meiner Anlage i.d.R. im Bereich von 10 bis 15 ms (und das war schon knapp).
Was für eine Steuerung setzt du denn ein ? Ggf. gibt es ja die Möglichkeit auf eine schnellere CPU auszuweichen ...

Gruß
Larry

 

[Speedo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Larry

Danke fürs schreiben.
Nein weiter rauf geht es nicht wir setzen eine Siemens 1517TF ein.
Es gibt noch zwei Möglichkeiten:
- Die Anlage auf zwei Steuerungen Verteilen sind jetzt aber bereits auf 3 würde heißen 4 Steuerungen ( die müssen aber ja auch wieder miteinander Kommunizieren)
- Eine 1518F nehmen ohne T und dann müsste man es anders angehen evtl. anders Programmieren.

Ich hab vor 3 Jahren wenig mit Motion bei Beckhoff gemacht und wir hatten dazumal mit etwa dem gleichen Umfang 2ms Zykluszeit.
Daher hat mich fast der Schlag getroffen als ich das mit 20ms sah.

Gruss Simon

 

[Funky]

Hallo Speedo,

wir sind gerade fertig mit vielleicht vergleichbaren Anlagen zu bauen.

Einige Daten:

Siemens 1517F
10x FQ G120C
2x S120 (je 4 Achsen)
ca. 600 EA-Punkte
7x Bildverarbeitung

Leistung 700 Teile/min (8 Spurig)

Mit der SPS haben wir eine Zykluszeit um die 3ms. Diese Zeit haben wir durch konsequente Symbolische Programmierung erreicht.

Allerdings haben wir keinen T - Anteil in der SPS. Es sind alles Einfachpositionieren mit Protokoll 111 & 30 (Sicherheit). Bei den FQ 352 & 30.

Eine andere Anlage hat zum vergleich folgende Daten:

Siemens 1518F
12x FQ G120C
26x S110
ca. 900 EA-Punkte
1x Bildverarbeitung
8x Temperaturreglung in SPS
usw.

Leistung 180 Teile/min (6 Spurig)

Zykluszeit SPS ca. 2ms





Harald

 

[Speedo]

Hallo Harald

Sehe ich das richtig die 700 sind auf 8 Spuren.
Dan ist es um einiges weniger Zeitkritisch... da du dann pro Linie "nur" 90 Stück hast pro Minute.

Das mit der 1518F ist ein möglicher Ansatz nur nicht befriedigend.

Wie ist das zu verstehen?

Diese Zeit haben wir durch konsequente Symbolische Programmierung erreicht.

Ich weiß das die Steuerung schneller ist wen ich nur Absolut Adressierung verwende. Aber das wäre ja genau das gegenteil von deiner aussage?

Gruss Simon

 

[Funky]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Simon,

bei 1500 SPS ist die reine symbolische Programmierung schneller. Wichtig ist auch, auf AWL zu verzichten.

Das Funktionell gleiche Programm mit einen Anteil von 40% AWL ist früher auf einen IPC 277D gelaufen. ca.6ms.

Nach Migration auf TIA V14 und der 1517F, lagen wir bei unter 10ms. Durch die Umstellung von AWL auf KOP (Kundenwunsch) und symbolischer Adressierung sind wir auf 3ms gekommen.

Ja unsere Anwendung ist um ca. 20% langsamer. Bei deiner Aufgabenstellung würde ich versuchen das die SPS die 10 MS nicht übersteigt.

Beim zweiten Beispiel ist der Programmumfang ca. das 4 fache. Viele Berechnungen. Die Anlage gibt es mit einer 1517F (TIA 13) ca. 8ms. und einer 1518F (TIA15) ca. 2ms. Wobei die Anlage mit der 1517 noch einen Anteil von 15% AWL hat.


Diese Werte sollen nur der Information dienen über die Geschwindigkeiten der SPSsen.

Harald

 

[PN/DP]

bei 1500 SPS ist die reine symbolische Programmierung schneller.

Vermutlich meinst Du eigentlich die Verwendung von nur "optimiertem Speicher" anstatt Speicher mit Standard-Zugriff?
Nur durch symbolische Programmierung anstatt absoluter Adressierung wird kein Programm schneller.

Harald

 

[vollmi]

Was genau steigert denn die Zykluszeit so enorm? Die TO Objekte? Oder wird in der Software womöglich was gemacht das man auch auf mehrere zyklen verteilen könnte?

 

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

... bei Deiner Anwendung solltest Du dank Interpolation und DSC (falls Du einen SINAMICS S120 / S210 einsetzt) mit einen IPO* Takt von 4 ... 8ms auskommen. Steht dieser im OB91/92 noch auf 1ms? Dann könnte das schon die Erklärung sein.
Ansonsten die zeitkritischen Programmteile in den PreServo- OB abarbeiten lassen.

Es gibt noch einen Baustein ("RT_Info" - oder so ähnlich). Da kann man sich dann anzeigen lassen, welche Zykluszeit welcher OB benötigt.
Falls du den Interpolatortakt z.B. bei 1ms hast, und Dein Motion-Teil bereits 0,9ms braucht, dann werden aus 2ms- OB1 Zyklus eben gleich mal 20ms. Wenn Du nun den Interpolator auf 4ms stellst, dann würde sich auch die OB1 Zyklus drastisch reduzieren.

PS.: An den Kommunikationsresourcen kann man auch noch drehen (also weniger für Kommunikation freigeben).

 

[mnuesser]

Wichtig ist definitiv den AWL Anteil zu killen, der läuft nur über einen separaten Interpreter in der CPU,
und ist damit das langsamste an Code den du generieren kannst.
Zumal man auch sehr leicht den AWL-Code durch SCL ersetzen kann.

 

[ducati]

Wichtig ist definitiv den AWL Anteil zu killen, der läuft nur über einen separaten Interpreter in der CPU,
und ist damit das langsamste an Code den du generieren kannst.
Zumal man auch sehr leicht den AWL-Code durch SCL ersetzen kann.

Ist das wirklich so, wo steht das? Ich dachte immer, AWL wird in der 1500er genauso compiliert wie KOP FUP SCL auch...
Gruss

 

[mnuesser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist das wirklich so, wo steht das? Ich dachte immer, AWL wird in der 1500er genauso compiliert wie KOP FUP SCL auch...
Gruss

Das stand mal in einer Veröffentlichung von Siemens... Anfangs war AWL ja auch kein Bestandteil der 1500er Sprachen... da stand auch sowas von Faktor 3 langsamer wenn ich das recht in erinnerung habe. Nächste Woche habe ich eine Produktionsbegleitungswoche, da versuche ich die Doku mal zu finden...

Gesendet von meinem SM-G950F mit Tapatalk

 

[rostiger Nagel]

Ist das wirklich so, wo steht das? Ich dachte immer, AWL wird in der 1500er genauso compiliert wie KOP FUP SCL auch...
Gruss

Auf der letzten 7 nach 5 haben Sie gesagt das interpretiert wird, AWL ist Gift für jede 1500er.

 

[mnuesser]

Auf der letzten 7 nach 5 haben Sie gesagt das interpretiert wird, AWL ist Gift für jede 1500er.

danke, das spart mir das raussuchen [emoji16]

Gesendet von meinem SM-G950F mit Tapatalk

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der aus SCL / FUP / KOP generierte Code wird vermutlich ebenfalls interpretiert werden. Nur AWL lässt sich überhaupt nicht optimieren.

 

[mnuesser]

Der aus SCL / FUP / KOP generierte Code wird vermutlich ebenfalls interpretiert werden. Nur AWL lässt sich überhaupt nicht optimieren.

ich vermute mal dass die den AWL Interpreter einfach nur rein gemacht haben, um Augenwischerei zu betreiben, frei nach der devise " Klar können Sie Ihre alte S5 direkt mit ner 1500er tauschen... "

Prinzipiell find ich es auch besser, ab und an mal die alten Zöpfe abzuschneiden und mal ein wenig nach links und rechts zu schauen...

Warum also nicht mal awl entsorgen und durch modernere Techniken ersetzen...

Gesendet von meinem SM-G950F mit Tapatalk

 

[Onkel Dagobert]

Ist das wirklich so, wo steht das? Ich dachte immer, AWL wird in der 1500er genauso compiliert wie KOP FUP SCL auch...

So kann man es z.Bsp. auch dem "Programmierleitfaden für S7-1200/S7-1500" entnehmen. Sollte es tatsächlich derartige Missverständnisse geben?


Nachtrag:
Was mir bekannt ist, ist dass die AWL-Register (Akkumulatoren, Adressregister, DB-Register) emuliert (nachgebildet) werden. Habt ihr das gemeint? Das bedeutet aber nicht dass der gesamte AWL-Code interpretiert wird. Der wird schon compiliert, oder sehe ich das falsch?

 

[Speedo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen


Danke erst für die Hilfe!!
Bin bald am Verzweifeln die Anlage steht noch nicht und ich muss schauen was an ich noch bringen kann.:-(

Wir sind bereits wieder einen Schritt weiter(weg).

AWL verwenden wir nicht es wird alles in SCL gemacht.
Unser Siemens Spezialist hat uns empfohlen den "Programm_Alarm" zu verwenden da wir die Fehler von 3 Steuerungen auf 2 HMI's Anzeigen wollen daher kommt dort jetzt noch 2500 Meldungen auf die Zykluszeit x 49us wen ich nicht nach Standard programmiere, kann ich nochmals was an Zykluszeit raus holen.

In dem Anlagen teil den wir mit dem Problem haben verwenden wir nur V90.
In einem Anderen Anlagen teil verwenden wir ausschließlich S120 dort ist die Zykluszeit aber auch bei 17ms. Dort versuch ich das mit dem OB91/92 mal.

Das Problem ist das eigentlich fasst alles zeitkritisch ist, da die Mechanik mit keiner Reaktionszeit der Steuerung gerechnet hat...
--> Uns wurde gesagt es sei REALTIME...!!!<-- :sc6:

Ich ken das einfach nicht! Ich hab 5 Jahre mit Beckhoff programmiert und alle meinten ja Beckhoff nicht so das wahre.
Jetzt komm ich zu Siemens und muss mir jeden Baustein 10 mal überlegen ob das jetzt Zykluszeit kritisch ist.
Ist das Siemens...? Muss ich jetzt mein Leben lang überlegen geht/geht-nicht?!?

 

[Larry Laffer]

Um dir konkrete Vorschläge machen zu können müßte man viel mehr über dein Programm wissen - also wie werden ganz konkret Dinge umgesetzt oder wo entstehen diese Zeiten.
Ganz generell :
- die T-Funktion (öfter als nötig aufgerufen) kann schon so etwas bewirken
- die HMI hat eher weniger Einfluß darauf - die holt sich ihre Daten nur ab
- eine leistungsstärkere CPU wird generell helfen. Die Frage bei deinem Siemens-Beckhoff-Vergleich läßt sich vielleicht auch schon damit beantworten ...

Gruß
Larry

 

[oliver.tonn]

--> Uns wurde gesagt es sei REALTIME...!!!<-- :sc6:

Ich ken das einfach nicht! Ich hab 5 Jahre mit Beckhoff programmiert und alle meinten ja Beckhoff nicht so das wahre.
Jetzt komm ich zu Siemens und muss mir jeden Baustein 10 mal überlegen ob das jetzt Zykluszeit kritisch ist.
Ist das Siemens...? Muss ich jetzt mein Leben lang überlegen geht/geht-nicht?!?

Wer hat das gesagt und was wurde damit gemeint? Es gibt hier im Forum so manchen Irrglauben (z.B. das man Dezimalzahlen konvertieren muss um Hexzahlen zu erhalten) der sich leider hartnäckig hält und die Aussage scheint mir auch auf einen solchen zu basieren. Warum auch immer denken viele, dass wenn es um Realtime oder auf Deutsch Echtzeit geht es nur um besonders schnelle Vorgänge geht, aber das ist Blödsinn, Realtime/Echtzeit steht nicht für schnell, sondern für vorhersagbar (deterministisch). Ein System ist echtzeitfähig, wenn dieses auf Ereignisse innerhalb einer definierten Zeit regiert, wobei die Höhe der Zeit je nach Anwendung unterschiedlich sein kann. Bei einer Temperaturregelung kann es z.B. ausreichend sein, wenn die Steuerung "nur" jede Sekunde neue Reglerwerte berechnet, soweit garantiert ist, dass Sie dies immer innerhalb dieser Zeit tut spricht man auch hier von Echtzeit. Bei Beckhoff hängt die Größe der erreichbaren Zykluszeit von der Leistungsfähigkeit der eingesetzten Hardware ab, außerdem gibt es eine Einstellung (Base Time) bei der Echtzeit die angepasst werden muss um kleinere Zykluszeiten zu erreichen.