Zykluszeiten... von Steuerungen

Zuviel Werbung?
-> Hier kostenlos registrieren
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. :confused:
Ist das Siemens...? Muss ich jetzt mein Leben lang überlegen geht/geht-nicht?!?

Natürlich musst du dir das überlegen. Und noch gemeiner, du musst dir nicht nur Gedanken über die Zykluszeit des Programms machen, sondern auch die Wandlungszeit der Analogkarten, der Remote IO, der komplexeren Sensorik etc.
Sonst könnts ja jeder.
 
Zuletzt bearbeitet:
Ich verstehe es nicht, wieso es nicht möglich ist, den Motion Anteil in eine D445-2 auszulagern und dort von mir aus 1mS ServoSynchronousTask zu fahren, und langsame Prozesse wie Rezeptverwaltung, Hardware-Diagnose und Schrittketten zusammen mit dem F-Anteil in einer moderaten 1512 F-CPU zu handeln ?

Jede Anlage beginnt mit einer validen Planung von Hardware, und einer redlichen Gegenüberstellung von benötigten Soft- und Hardwaremitteln in Abhängigkeit von den gewünschten Leistungsdaten. Dabei sollte man auch tatsächlich möglichst sachgerechte Mittel verbauen. Wenn man hier 2€ an der falschen Stelle gespart hat, dann gibt man in der Programmierung später 200€ aus um des noch irgendwie zum Laufen zu bringen, und läuft Gefahr, daß es auch noch endlos häßlich wird und eine Einmal-Lösung, die nicht übertragbar ist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich verstehe es nicht, wieso es nicht möglich ist, den Motion Anteil in eine D445-2 auszulagern und dort von mir aus 1mS ServoSynchronousTask zu fahren, und langsame Prozesse wie Rezeptverwaltung, Hardware-Diagnose und Schrittketten zusammen mit dem F-Anteil in einer moderaten 1512 F-CPU zu handeln ?
99% ACK
Also wenn man aus der Codesys - Ecke kommt, dann kommt man wohl mit einer SIMOTION schneller zurecht als mit einer SIMATIC. Wie du es hier beschrieben hast, hätte man das machen können und man ware hier auf diese Diskussion gar nicht gestoßen. SIMOTION hat halt ne tierische Performance und wenn man will kann man ja noch eine daneben hängen (Stichwort Multimaster). Aber die S7-1517TF hat schon auch Dampf.
Aber der Themenstarter hat ja offensichtlich die einfachste und schnellste Änderung (Anpassen des OB91/92 Task noch gar nicht umgesetzt). Zumindest wurde diese Emfehlung schon gegeben.
Und es gibt eben genügend Anwendungen wo die Variante mit einer S7-1500TF einfach am besten passt.
Beispiel Regalbediengerät:
Da läuft Standardprogramm, die RBG SAFETY- Bib und Motion- Teil direkt auf einer Steuerungsplattform und die Antriebe sind einfache Drehzahlsteller (ohne dass man sich in eine weitere Programmierumgebung einarbeiten muss, Simulationsmöglichkeiten usw.).
Oder eben Verpackungsmaschinen: gleicher Ansatz und SINAMICS V90 oder S210 als Antrieb rein, ...
 
Zuletzt bearbeitet:
Ich hab wiedermal Zeit...

- T-Bausteine wurden nur einmal verwendet
- der OB91 ist bereits auf 4ms.
- Zeit unkritische Bereiche haben wir in einen 10ms OB ausgelagert

Jede Anlage beginnt mit einer validen Planung von Hardware, und einer redlichen Gegenüberstellung von benötigten Soft- und Hardwaremitteln in Abhängigkeit von den gewünschten Leistungsdaten. Dabei sollte man auch tatsächlich möglichst sachgerechte Mittel verbauen. Wenn man hier 2€ an der falschen Stelle gespart hat, dann gibt man in der Programmierung später 200€ aus um des noch irgendwie zum Laufen zu bringen, und läuft Gefahr, daß es auch noch endlos häßlich wird und eine Einmal-Lösung, die nicht übertragbar ist.

Da war ich leider noch nicht hier, kann daher nicht sagen was validiert wurde…

Ich verstehe es nicht, wieso es nicht möglich ist, den Motion Anteil in eine D445-2 auszulagern und dort von mir aus 1mS ServoSynchronousTask zu fahren, und langsame Prozesse wie Rezeptverwaltung, Hardware-Diagnose und Schrittketten zusammen mit dem F-Anteil in einer moderaten 1512 F-CPU zu handeln ?


Der ist doch nur für S120 einsetzbar?
Man hat definiert das man möglichst nur V90 aus Kostengründe einsetzen will… à sind wir wieder bei der Validierung…

99% ACK
Also wenn man aus der Codesys - Ecke kommt, dann kommt man wohl mit einer SIMOTION schneller zurecht als mit einer SIMATIC. Wie du es hier beschrieben hast, hätte man das machen können und man ware hier auf diese Diskussion gar nicht gestoßen. SIMOTION hat halt ne tierische Performance und wenn man will kann man ja noch eine daneben hängen (Stichwort Multimaster). Aber die S7-1517TF hat schon auch Dampf.

Im anderen Anlagen teilhaben wir 5x CU320-2 PN das wären dann Multimaster?

Natürlich musst du dir das überlegen. Und noch gemeiner, du musst dir nicht nur Gedanken über die Zykluszeit des Programms machen, sondern auch die Wandlungszeit der Analogkarten, der Remote IO, der komplexeren Sensorik etc.
Sonst könnts ja jeder.

Danke das war eine ausführliche Hilfe…
Schon mal mit TC3/Beckhoff entwickelt...?

Besten Dank für eure Hilfe!
 
" SIMOTION / V90 ... "
Der ist doch nur für S120 einsetzbar?
Man hat definiert das man möglichst nur V90 aus Kostengründe einsetzen will… à sind wir wieder bei der Validierung…
Der V90 ist in Zusammenhang mit einer S7-1500 recht einfach in Tia Portal konfigurierbar. Bei SIMOTION denkt man schon immer eher an einen S120, aber der V90 wäre ja auch per GSD an einer SIMOTION betreibbar.

Im anderen Anlagen teilhaben wir 5x CU320-2 PN das wären dann Multimaster?
Die CU320-2 ist eine Multiachs- Antriebsregelungsbaugruppe (bis zu 6 Achsen in feldorientierder Regelung oder bis 12 U/f). Vorteile eine solchen Architektur sind z.B. dann auch schnelle totzeifreie Drehmomentkopplungen oder Leistungsteilparallelschaltungen usw.
Durch die Multimasterfunktionalität hast Du den Vorteil, dass Du eine weitere Steuerung nehmen kannst, wenn die Rechenleistung einer nicht mehr ausreicht. Aber bei SIMOTION wären das dann schon recht viele (z.B. bei der Performance eienr D455). Nach meiner Kenntnis unterstützt das die S7-1500 heute nicht, aber wie Darco schon angesprochen hat, kann man ja das Motion Thema auch in einer SIMOTION auslagern und bleibt im gleichen Automatisierungsumfeld.
Ausserdem kannst Du bei SIEMENS auch Motion Rechenleistung in den Antrieben nutzen.
Schon mal mit TC3/Beckhoff entwickelt...?
Na dann nehm mal eine SIMOTION. ;)
Aber bin mir recht sicher, dass Deine Anwendung mit der notwendigen Performance auf einer S7-1517 laufen wird (zumindest was ich oben gelesen habe).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Na dann nehm mal eine SIMOTION. ;)

Ja das hat isch nun auch erledigt...
Laut unserem Spezi. bei Siemens wird die Simotion vermutlich nächstens das Ende seines Lebenszyklus erreichen...
Daher für eine neu Entwicklung nicht geeignet.

Aber bin mir recht sicher, dass Deine Anwendung mit der notwendigen Performance auf einer S7-1517 laufen wird (zumindest was ich oben gelesen habe).

Wir haben eine S7-1517TF
Daher verlieren wir noch was an die F.
Und dann reicht es nicht mit der Performance.
Die SPS braucht zu lange die Mechanik muss maximal in 25ms reagieren können...
Unser Steuerung lauft aber bereits auf 23ms.
 
Zuletzt bearbeitet:
Danke das war eine ausführliche Hilfe…
Schon mal mit TC3/Beckhoff entwickelt...?

Ja hab ich auch schon. Bei Beckhoff, überhaupt bei Codesys ist halt viel mehr Gewicht auf verschiedene Tasks gelegt.
Das gibt es bei Siemens auch. Aber gang und gäbe ist halt, das alles im OB1 läuft und das killt dir bei grösseren Projekten die Zykluszeit.
Und ich nehme an das ist derzeit auch bei dir der Fall. 23ms ist eine Ansage. Muss wirklich alles in diesem OB laufen? Muss alles in einem Zyklus gerechnet werden oder kann man einzelne Zeitfresser auf mehrere Zyklen aufteilen.
Man kann priore Aufgaben ja auch in höher Priorisierte OBs verstauen.

die Zyklusobs sind nunmal am niedrigsten priorisierten OBs. Du könntest deine reaktionsschnellen Aktionen auch in höher priorisierte Obs verpacken. Z.B. Weckalarme, das bedingt aber ein durchdachtes Programm. Denn es darf darin nichts aufgerufen werden das unkontrollierte Zykluszeiterhöhungen verursacht und womöglich länger wird wie der Weckalarmtakt.
Wenn du also alle 5ms einen Weckalarm aufrufst, darf der keine längeren Durchläufe als <5ms haben.

Dann gäbe es noch die TaktsynchronOBs. Die richten sich z.B. nach deinem Peripherietakt. Kann durchaus Sinn machen.

mfG René
 
Zur Unterhaltung einer Party trägt niemand so viel bei wie diejenigen, die gar nicht da sind.
( Zitat Audrey Hepburn)

SIMOTION hat mit SIMOSIM und OOP in Vollendung, einen weitern Entwicklungsschritt im High-End Motion Bereich vollzogen.
Weitere Inovationen werden in den folgenden jahren umgesetzt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zur Unterhaltung einer Party trägt niemand so viel bei wie diejenigen, die gar nicht da sind.
( Zitat Audrey Hepburn)

SIMOTION hat mit SIMOSIM und OOP in Vollendung, einen weitern Entwicklungsschritt im High-End Motion Bereich vollzogen.
Weitere Inovationen werden in den folgenden jahren umgesetzt.

Der Spezi. hat mich gefunden.... :s19:

Wo findet man da Infos... Gibt es da ne aussage das weiter Innovationen kommen mit Simotion?
 
... Innovationen zeigen die Hersteller auf Messen (die dann hoffentlich in den nächsten Monaten auch in das Produkt kommen ;) ) - zur SIMATIC findest Du ja auch noch nichts, was in einer V16 / 17 usw. kommen soll.
Aber ich habe schon den Eindruck, dass SIEMENS die SIMOTION offensichtlich gerne als technischen Vorreiter nutzt um Features dann in der SIMATIC einzuführen (v.a. auch was den Motion Part betrifft).

Aber nochmal zu Deiner Anwendung:
Schau doch mal welche Last die einzelnen Task´s (OB´s) haben ("RuntimeInfo"). Zeitkritische Teile könnte man in den PreServo-OB packen, der dann konsistent vor dem Servo-OB ausgeführt wird. Falls Du merkst, dass auch der Motion Part entscheident zur Last beiträgt, würde ich nochmal versuchen die Zykluszeit zu variieren, oder wenn Du auch einfache Positionierachsen hast (z.B. Zustellachsen etc.), diese per Einfachpositionierer zu verfahren (also Interpolator läuft im Antrieb). Das könnte man auch für Gleichlauf-/Kurvenscheibenachsen im S120 per "DCB-Gleichlauflauf"machen.
Wenn Du statt mit PLC-Open Befehlen gleich den "AxisControl Block" genommen hast, dann ähnelt dieser auch den Ansteuerbaustein für den DCB- Gleichlauf. D.h. dem Anwenderprogramm kann es im Prinzip egal sein, wo (Steuerung oder Antrieb) nun die Lagesollwertinterpolation läuft. Die TO´s sind halt aus Sicht der Usabilty und Diagnose recht schön (das ist schon ein Vorteil zentraler Motion Control Architekturen).
 
Zuletzt bearbeitet:
Diese Optimierungen haben wir auch bereits gemacht.
Evtl. werden wir den Technologie teil in der Steuerung wegnehmen wo möglich.
Ein Teil der Maschine der eine eigene Steuerung hat werden wir vermutlich die 1518F (daher ohne T) nehmen da die Technologie hier nicht gebraucht wird und wir mit "normalen" Fahrbefehlen arbeiten können.

Mal schauen...
Danke aber allen die Helfen wollten für die Inputs.
 
Zurück
Oben