# S7 1200 MC-MoveAbsolute



## alfred0905 (27 November 2019)

Hallo!

Stehe vor einem kleinen Rätsel - ich würde gerne eine Achse absolut nach einem analogen Input positionieren, stehe aber vor dem Problem dass im MC_MoveAbsolute Block die Bewegung ja erst mit steigender Flanke des Execute Inputs ausgeführt wird. Gibt es eine Möglichkeit, dass die Achse quasi dem Input dauerhaft folgt, mit der Geschwindigkeit mit der sich die Sollposition verändert, solange die eingestellte Höchstgeschwindigkeit nicht erreicht ist?

Habe versucht das durch den 10Hz Taktmerker am Execute zu lösen, besonders flüssig funktioniert das aber leider nicht.

Danke im Voraus und liebe Grüße 

Alfred


----------



## zako (27 November 2019)

Schau mal, ob es bei er S7-1200 wie bei der S7-1500 auch eine Variable

"Axis".override.velocity gibt. Der sollte man zyklisch einen Wert zuweisen können.


----------



## alfred0905 (27 November 2019)

Hallo Zako, 

ich glaube, das würde mein Problem nicht Lösen. Ich möchte Quasi die Sollposition vorgeben und er soll diese auf dem schnellsten Weg anfahren - wie ein P Regler quasi Soll- und die errechnete Ist vergleichen.


----------



## Captain Future (28 November 2019)

Den Sollwert sichern und mit dem Sollwert auf ungleich vergleichen um bei Änderung  damit eine Flanke zu erzeugen... das sollte schon besser sein als mit einem 10 kHz Taktmerker das Ganze zu lösen....

Anhang anzeigen 47795


----------



## Captain Future (28 November 2019)

Wie genau mußt du Positionieren ?


----------



## alfred0905 (29 November 2019)

Super, funktioniert so!

Anwendung ist in einem Springbrunnen eine Schrittmotorgesteuerte Düse, die sich um 180° drehen lässt auf einer Achse. Die Positionsvorgabe kommt über das Lichtpult über2 Artnet Kanäle in die S7 die zu einem UINT zusammengefasst werden, das funktioniert schon ganz gut.

Die Bewegungen sind zwar nicht perfekt flüssig, aber ich denke besser lässt es sich auch nicht realisieren, vielen Dank!


----------



## Captain Future (29 November 2019)

Schön wenn es schon besser klappt...

Du kannst Dir auch noch eine Totzone basteln damit das ganze nicht auf jede kleinste Änderung reagiert....
Muss man halt etwas spielen und versuchen was das Beste ist

Gruß


----------



## alfred0905 (26 März 2022)

Hallo! Bin gerade dabei das Projekt nochmal etwas aufleben zu lassen - Stand bis jetzt: 




Das mit dem MoveAbsolute funktioniert leider immer noch etwas suboptimal: Wenn von der Steuersoftware ein Sinusverlauf an Sollpositionen vorgegeben wird, ist insbesondere bei sehr langsamen Bewegungen ein sehr starkes Ruckeln zu sehen - vermutlich wegen der parametrierten Beschleunigung/Verzögerung.

Als Notlösung habe ich jetzt den Velocity Eingang auch auf die externe Steuersoftware gelegt - für langsame Bewegungen muss ich jetzt halt schauen dass die Velocity kleiner ist als die Differenz zwischen den letzten beiden Positionsvorgaben, zum Programmieren ist das aber wirklich mühsam.

Gibt es wirklich eine Lösung, bei der die Sollposition von Extern kommt und angefahren wird, ohne dass für jede Änderung ein Execute getriggert werden muss?


----------



## Blockmove (26 März 2022)

Solche "Spielereien" sind technisch oft aufwändiger als Aufgaben im Industrieumfeld.
Ich denke du wärst mit µController-Lösung mit Aduino oder EPS32 besser bedient.


----------



## alfred0905 (26 März 2022)

Blockmove schrieb:


> Solche "Spielereien" sind technisch oft aufwändiger als Aufgaben im Industrieumfeld.
> Ich denke du wärst mit µController-Lösung mit Aduino oder EPS32 besser bedient.


Da gebe ich dir absolut Recht, ich hab da schon so viele Probleme vor mir gehabt..

Ist halt schon ein wirklich sehr umfangreiches Projekt - hab allein 14 S7-1214C neben einigen anderen Steuerungen da laufen

Hätte halt gehofft mit der MotionControl eine "out of the box" Lösung zu bekommen, die schön auf eine Hutschiene passt und nicht viel Programmieraufwand benötigt - aber habe mich wohl wirklich zu früh gefreut. Naja, Standardaufgaben macht die S7 schon wirklich gut.


----------



## kafiphai (26 März 2022)

Beitrag im Thema 'Differenzdrehzahl zweier S210 auf eine Virtuelle Achse übertragen'
https://www.sps-forum.de/threads/di...-virtuelle-achse-übertragen.97033/post-729072


----------



## alfred0905 (27 März 2022)

kafiphai schrieb:


> Beitrag im Thema 'Differenzdrehzahl zweier S210 auf eine Virtuelle Achse übertragen'
> https://www.sps-forum.de/threads/differenzdrehzahl-zweier-s210-auf-eine-virtuelle-achse-übertragen.97033/post-729072


Habe etwas recherchiert, kann sein dass das nur auf S7-1500 CPUs funktioniert?


----------



## Heinileini (27 März 2022)

alfred0905 schrieb:


> Stehe vor einem kleinen Rätsel - ich würde gerne eine Achse absolut nach einem analogen Input positionieren, stehe aber vor dem Problem dass im MC_MoveAbsolute Block die Bewegung ja erst mit steigender Flanke des Execute Inputs ausgeführt wird. Gibt es eine Möglichkeit, dass die Achse quasi dem Input dauerhaft folgt, mit der Geschwindigkeit mit der sich die Sollposition verändert, solange die eingestellte Höchstgeschwindigkeit nicht erreicht ist?


Ich stehe auch vor einem Rätsel. Kannst Du irgendetwas dazu sagen, woran es scheitert?
Müssten die positiven Flanken schneller erfolgen und wo liegt die Obergrenze?
Oder müssten die Flanken in grösseren Abständen aufeinander folgen, damit bei langsamerem Ansteigen/Abfallen des AnalogSignals die Bewegung nicht so "zackig" erfolgt, sondern der Antrieb sich Zeit nehmen kann, die langsame Änderung auch langsam nachzuvollziehen?
Vermutlich müsstest Du die Zeit zwischen zwei aufeinanderfolgenden Flanken an die ÄnderungsGeschwindigkeit des AnalogSignals anpassen?

PS:
Wo kommt das AnalogSignal her? Gibst Du es von der SPS aus? Kannst Du es in die SPS einlesen?

PPS:
Du sprichst von SinusVerlauf. In welcher Grössenordnung liegt die Frequenz bzw. die PeriodenDauer?



alfred0905 schrieb:


> Ich möchte Quasi die Sollposition vorgeben und er soll diese auf dem schnellsten Weg anfahren - wie ein P Regler quasi Soll- und die errechnete Ist vergleichen.


Auf dem schnellsten Weg anfahren? Das scheint mir bei langsamen Änderungen des AnalogSignals genau der falsche Weg zu sein.


----------



## Onkel Dagobert (27 März 2022)

alfred0905 schrieb:


> ... Ich möchte Quasi die Sollposition vorgeben und er soll diese auf dem schnellsten Weg anfahren - wie ein P Regler quasi Soll- und die errechnete Ist vergleichen.


Warum nimmst du nicht einen P- oder PI-Regler?


----------



## alfred0905 (27 März 2022)

Heinileini schrieb:


> Ich stehe auch vor einem Rätsel. Kannst Du irgendetwas dazu sagen, woran es scheitert?
> Müssten die positiven Flanken schneller erfolgen und wo liegt die Obergrenze?
> Oder müssten die Flanken in grösseren Abständen aufeinander folgen, damit bei langsamerem Ansteigen/Abfallen des AnalogSignals die Bewegung nicht so "zackig" erfolgt, sondern der Antrieb sich Zeit nehmen kann, die langsame Änderung auch langsam nachzuvollziehen?
> Vermutlich müsstest Du die Zeit zwischen zwei aufeinanderfolgenden Flanken an die ÄnderungsGeschwindigkeit des AnalogSignals anpassen?
> ...



Der Analogwert "Sollposition" kommt über ArtNet (also Netzwerk) mit 44hz in die SPS (als 16bit Variable)

Momentan ist das so gelöst dass Execute dann ausgelöst wird wenn die Sollposition aus dem aktuellen Zyklus ungleich dem Sollwert des letzten Zyklus ist - das ist dann die Variable "Flanke".

Wird nun dieser Wert z.B. entlang einer Sinuskurve verändert fängt das ganze unheimlich zu ruckeln an - ich vermute mal weil quasi ein neues Execute ausgelöst wird bevor der letzte Auftrag fertig ausgeführt wurde - insbesondere wenn wenig Unterschied zwischen den Sollwerten ist, weil der Antrieb ja zwischen jedem "Execute" mit der eingestellten Beschleunigungs- und Verzögerungsgeschwindigkeit anlaufen und wieder stoppen will.

Verändert man den Sollwert entlang eines Rechtecks funktioniert es wunderbar, weil eben ausreichend Zeit zwischen zwei neuen Sollwerten ist um die Aktion vollständig auszuführen, das ist nur leider nicht ganz die Idee von dem Projekt immer nur fixe Positionen anfahren zu können und keine schönen Bewegungen vorgeben zu können.


Das mit dem P- bzw PI Regler ist ein interessanter Ansatz - ich fürchte nur relativ kompliziert umzusetzen, oder habe ich was übersehen? Muss ja trotzdem die Beschleunigungs- und Verzögerungszeiten berücksichtigen, ohne dem Technologieobjekt könnte das mühsam werden.


----------



## Heinileini (27 März 2022)

alfred0905 schrieb:


> Der Analogwert "Sollposition" kommt über ArtNet (also Netzwerk) mit 44hz in die SPS (als 16bit Variable)


Ja, ich muss gestehen, mein Ansatz, die Abstände zwischen den Flanken ggfs zu verlängern war - für sich allein betrachtet - falsch.
Dein auf-schnellstem-Wege-Ansatz allerdings auch.
Ich denke mittlerweile, Zako war mit seinem override-velocity-Ansatz schon in Beitrag #2 auf der richtigen Spur.
Nicht auf schnellstem Wege, sondern mit einer an die Steigung angepassten Geschwindigkeit sollte angestrebt werden.
Wenn Du in der SPS das Analog-Signal darauhin untersuchen UND die Geschwindigkeit dem Antrieb jeweils entsprechend vogeben kannst, dann sollte Dein Vorhaben umsetzbar sein.
Muss eigentlich die mechanische Bewegung möglichst synchron (unverzüglich) dem AnalogSignal folgen, oder kannst Du mit einer gewissen Verzögerung leben?


----------



## alfred0905 (27 März 2022)

Heinileini schrieb:


> Ja, ich muss gestehen, mein Ansatz, die Abstände zwischen den Flanken ggfs zu verlängern war - für sich allein betrachtet - falsch.
> Dein auf-schnellstem-Wege-Ansatz allerdings auch.
> Ich denke mittlerweile, Zako war mit seinem override-velocity-Ansatz schon in Beitrag #2 auf der richtigen Spur.
> Nicht auf schnellstem Wege, sondern mit einer an die Steigung angepassten Geschwindigkeit sollte angestrebt werden.
> ...



Override velocity geht leider nur bei der S7 1500 - aber ja der Ansatz ist wahrscheinlich nicht verkehrt, sich die Änderungsrate der Sollwerte rauszurechnen und daraus die Sollgeschwindigkeit zu errechnen.

Eine gewisse Verzögerung wäre prinzipiell nicht schlimm, ich würde mal sagen bis 100ms wäre es verkraftbar.

Aber wie es aussieht werde ich die S7 1200 gegen etwas anderes ersetzen müssen - S7 1500T, Beckhoff oder vermutlich am besten (und leistbarsten) wirklich Mikrocontroller - fließen wahrscheinlich wieder zig Arbeitsstunden rein ):


----------



## Heinileini (27 März 2022)

alfred0905 schrieb:


> Override velocity geht leider nur bei der S7 1500 - aber ja der Ansatz ist wahrscheinlich nicht verkehrt, ...


Wir müssen uns ja nicht auf Override versteifen, vorausgesetzt die Geschwindigkeit kann "direkt" in kleineren zeitlichen Abständen variiert werden.


----------



## alfred0905 (27 März 2022)

Ja das wäre ja prinzipiell möglich die Geschwindigkeit mit jeder oder jeder zweiten Sollwertveränderung anzupassen - wo ich noch ein wenig Sorge habe ist das durch jeden neuen Execute der letzte Auftrag abgebrochen wird und die Achse dadurch abbremst..


----------



## Michitronik (7 April 2022)

HI,

hier mal eine einfache Idee. Man kann den Motion Befehl ja durch einen weiteren ablösen.
Also in dem man einen MC_MoveAbsolute durch eine anderen MC_MoveAbsolute mit der gleichen Sollwertquelle und Achs TO ablöst. Die erreicht man, wenn jetzt der erste auf die positive Flanke einer Trigger Variable reagiert und der zweite auf die negative Flanke des selben Triggers, dann erfolgt ein Ablösen des aktuell aktiven MC Befehls. Die Dokumentation zu PLC_OPEN "Motion Control" beschreibt das Ablöseverhalten von Motion befehlen und ich meine mich zu erinnern, dass MC_MoveAbsolute durch eine weiteren MC_MoveAbsolute abgelöst werden kann (Überschleifen der Fahrbewegung).


Habe hier mal ein Beispiel mit angehängt, wo der Trigger innerhalb eines Cyclic OBs, der alle 100ms aufgerufen wird getoggelt wird und dann jeweils abwechselnd die MC Befehle getriggert werden.

Was die maximale sinnvolle Frequenz angeht, würde ich behaupten, dass sie von der Anschaltung des Antriebes abhängt (ProfiDrive oder PTO) und was hier die erreichbaren Zykluszeiten sind.


----------



## alfred0905 (10 April 2022)

Spannende Idee, werde ich sobald ich wieder beim Projekt bin einmal versuchen - für mich stellt sich nur die Frage ob nicht ein erneutes triggern des execute inputs denselben Effekt hat wie einen zweiten MC_MoveAbsolute Baustein zu verwenden?

Ich berichte gerne sobald ich es getestet habe! Antrieb ist über PTO - 100ms ist definitiv zu langsam um eine flüssige Bewegung zu erzeugen, aber ich werde es einmal austesten!


----------

