# Zykluszeiten... von Steuerungen



## Speedo (5 Januar 2018)

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 (5 Januar 2018)

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 (5 Januar 2018)

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 (5 Januar 2018)

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 (5 Januar 2018)

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 (5 Januar 2018)

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 (5 Januar 2018)

Funky schrieb:


> 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 (5 Januar 2018)

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 (5 Januar 2018)

... 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 (6 Januar 2018)

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 (6 Januar 2018)

mnuesser schrieb:


> 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 (6 Januar 2018)

ducati schrieb:


> 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 (6 Januar 2018)

ducati schrieb:


> 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 (6 Januar 2018)

rostiger Nagel schrieb:


> 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 (6 Januar 2018)

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


----------



## mnuesser (6 Januar 2018)

Thomas_v2.1 schrieb:


> 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 (6 Januar 2018)

ducati schrieb:


> 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 (17 Januar 2018)

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 (17 Januar 2018)

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 (17 Januar 2018)

Speedo schrieb:


> --> 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.


----------



## vollmi (18 Januar 2018)

Speedo schrieb:


> 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?!?



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.


----------



## Draco Malfoy (22 Januar 2018)

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.


----------



## zako (22 Januar 2018)

Draco Malfoy schrieb:


> 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, ...


----------



## Speedo (23 Januar 2018)

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



Draco Malfoy schrieb:


> 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…



Draco Malfoy schrieb:


> 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…



zako schrieb:


> 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?



vollmi schrieb:


> 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!


----------



## zako (27 Januar 2018)

Speedo schrieb:


> " 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. 



Speedo schrieb:


> 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.


Speedo schrieb:


> 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).


----------



## Speedo (30 Januar 2018)

zako schrieb:


> 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.



zako schrieb:


> 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.


----------



## vollmi (30 Januar 2018)

Speedo schrieb:


> 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é


----------



## HighEnd (30 Januar 2018)

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.


----------



## Speedo (30 Januar 2018)

HighEnd schrieb:


> 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?


----------



## zako (31 Januar 2018)

... 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).


----------



## Speedo (13 März 2018)

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.


----------

