SPS-Trajektorienplaung für Maxon IDX Motoren im CSP-Modus

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das bedeutet, du bekommst alle 5 s ein Datenpaket, das die Sollpositionen für die nächsten 10 s beschreibt.
Diese Daten verwendest du, um die Position der Achsen für die nächsten 5 s kontinuierlich nachzuführen – dann kommt das nächste Paket.

Im Idealfall brauchst du also immer nur die Informationen aus dem Zeitfenster 0…5 s, um die Bewegung zu planen.
Die Werte für 6…10 s helfen nur bei der Glättung und Vorausberechnung, z. B. für bessere Bahnverläufe oder frühzeitige Richtungsänderungen.
(Klingt übrigens nach einer sehr präzisen Anwendung – das ist doch nichts Militärisches? )

Anhand deiner Winkelangaben (z. B. 320° → 140°) sieht es so aus, als wären die Achsen korrekt skaliert und die Motoren sauber in Betrieb genommen.
Wenn du z. B. der X-Achse 45° und der Y-Achse 60° vorgibst – werden diese Winkel dann auch exakt angefahren?
Das ist wichtig, um auszuschließen, dass noch irgendwo Skalierungs- oder Umrechnungsfehler drinstecken.

Wenn das soweit passt, dann ist der CSP-Modus definitiv die richtige Wahl – gerade bei kontinuierlicher Bahnansteuerung.
Auch für das Einfahren in eine Startposition brauchst du keine parallele PtP-Steuerung – du kannst im CSP-Modus einfach die gewünschte Position senden.
Falls das zu einer Überlastung der Achsen führt (z. B. zu große Sprünge, Schleppfehler), kannst du das auf zwei Arten lösen:

• durch ausreichend feine Zwischenwerte, sodass die Bewegung sanft verläuft, oder
• durch temporäres Deaktivieren des Schleppfehler-Monitorings, während die Position „vorgegeben“ wird

Damit man dir hier im Forum gezielter helfen kann, wären noch folgende Informationen hilfreich:

• Welche Software genau verwendest du (z. B. TwinCAT 3.1 mit Motion Library)?
• Wie berechnest du aktuell die Sollwerte zwischen den gelieferten Datenpunkten?
  (Lineare Interpolation? Spline? Einfach „immer zum nächsten Punkt“?)

 

[herbi01]

Nein es wird defnitiv nicht für militärische Zweche verwendet. Die Antenne befindet sich auf dem Dach der Hochschule und gehört auch dieser.

Genau, es werden nur die Punkte von 0-5s verwendet. Die anderen werden nicht gebraucht, beziehungsweise im nächsten Zyklus überschrieben und entsprechend an im Bereich von 0-5s gesetzt. Es kommt nie zu Timing-Problem bei der Übermittlung von PC zu SPS, dies habe ich genügend verifiziert.

Die Sprünge geschehen sehr exakt, also praktisch ohne Fehler (vernachlässigbar, da im tiefen Miligrad-Bereich). Eine Überlastung konnte ich bis anhin nicht festellen, der Überwachte Strom, als auch die Geschwindigkeit blieben im Grünen-Bereich des Motors.

Software

• Twincat 3.1 mit Motion Library
• die erhaltenen Datenpunkte werden intern linear auf eine Auflösung von 10ms interpoliert (Anpassung auf 4ms möglich)
• anschliessend erfolgt die Umrechnung in die Motorspezifische-Einheit
• die erwartete Sollkurve weisst keinerlei Schwingungen oder sonstiges auf, erst im Antrieb stimmt diese nicht mehr überein

 

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

die erwartete Sollkurve weisst keinerlei Schwingungen oder sonstiges auf, erst im Antrieb stimmt diese nicht mehr überein

Diese Aussage irritiert mich sehr.

Welche Sollwert-Kurve wird an den Antrieb ausgegeben?
Wie kann der Sollwert im Antrieb davon abweichen?
Wie verhält sich der Istwert in Bezug auf den Sollwert?

Kannst du hier mal eine Aufzeichnung einstellen, die diese 3 Werte in einem Diagramm darstellen?

 

[herbi01]

Ich verstehe die Verwirrung. Ein Dartsellung aller drei Kurven in einem Bild ist nicht Übersichtlich, ich betrachte lieber den Fehler zwischen den einzelnen Kurve.

1. Unterschied_Soll_SPS_vs_SOLL_IDX: Vorgegebene Kurve in der SPS - Kurve welche in der SPS ankommt.
2. Unterschied_Soll_SPS_vs_IST : der effektive Fehler während eines Überfluges, also die Abweichung zwischen der vorgebenen Kurve von der SPS und der wirklichen IST Positon der Antriebe.
3. Unterschied_Soll_IDX_vs_IST : Fehler zwischen Sollkurve in den Antrieben und der IST-Position der Antriebe. Dieses Bild ist nicht wirklich aussagekräftig, da der zurückgeliferte Wert der IDX sehr stark schwankt.

 

[herbi01]

aber es ist ersichtlich das der Fehler bezüglich der beiden Sollkurven und von Sollkurve (SPS) zu IST-Position gleich ist. Das bestätigt mir, dass die Nachführung korrekt ist, einzig bei der Übermittlung der Werte stimmt es nicht

 

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dann entspricht der „Sollwert SPS“ doch wie es sein soll, dem „Sollwert IDX“!?

Es wäre schön, wenn du den Sollwert und den Istwert in einem Diagramm hättest zeigen können.
(bei Verwendung unterschiedlicher Farben kann man die gut auseinanderhalten)

Zusätzlich ist die Darstellung „Sollwert – Istwert“ ist auch gut, aber es wäre hilfreich, wenn die Achsen beschriftet wären.
Sind es Winkel oder Inkremente bei den Encoder-Werten?
Falls es wie erwartet Inkremente sind, wäre die Info wichtig, wie viele Inkremente ein Grad sind…

 

[herbi01]

Das Diagramm zeigt doch eindeutig, dass die IST-Position nicht dem eingentlich vorgesehen folgt, sondern der falsch übermittelten Position durch MoveAbsolute. Oder stehe ich gerade völlig auf dem Schlauch? also ich beziehe mich auf die beiden Bilder die nahezu identisch sind.

Ich bin gerade dran, dass von dir gern gesehen Diagramm zu erstellen

 

[Cassandra]

Ich sehe in den Diagrammen Abweichungen an der X-Ache von bis zu 20000, bei der Y-Achse bis zu -10000.
Allerdings ohne Information, was diese Werte bedeuten!

In Beitrag #5 zeigst du eine Sollkurve, die gemächlich von ~3 nach ~6000000 fährt
Entsprechen diese Einheiten denselben Inkrementen?
Mit welchem Tool erstellst du diese Aufzeichnungen?

 

[herbi01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jetzt wird das Problem, das ich anspreche, deutlicher sichtbar:
Die Ist-Position folgt nicht der ursprünglich intendierten Soll-Kurve, sondern der vom Antrieb berechneten „falschen“ Soll-Kurve (hier als „effektiv“ bezeichnet).


Mir ist bewusst, dass es sich dabei nur um sehr geringe Abweichungen auf der X- und Y-Achse handelt.
Allerdings handelt es sich um eine Antennennachführung, bei der diese Achspositionen in Azimut- und Elevationswinkel umgerechnet werden. Diese Umrechnung ist nicht linear, das bedeutet:
Bereits kleine Positionsfehler in X und Y können sich erheblich auf die resultierende Raumrichtung auswirken.


Das zuvor gepostete Diagramm war nicht korrekt beschriftet – hier ist die korrigierte Version.
Ich hatte zuvor einen Denkfehler gemacht: Die dargestellten Werte repräsentieren nun die mechanischen Winkel der Antenne in Grad – also nach korrekter Rückskalierung von Encoderwerten und Berücksichtigung der Getriebeübersetzung.

 

[Cassandra]

Jetzt wird das Problem, das ich anspreche, deutlicher sichtbar:

Ich werde aus den Angaben nicht richtig schlau. Bei der aktuellen Darstellung sieht es nach einem festen Offset von ¼ Grad aus.

Wieso funktioniert die Positionierung (abgesehen vom Offset) plötzlich, obwohl PtP und CSP-Modus im Widerspruch stehen?
Wieso zeigst du plötzlich nur noch 45s, anstatt den 2 Minuten der vollständigen Nachführung?
Wieso wurde aus der Kurve ein gerader Strich?

 

[herbi01]

wenn ich dir die gesamten 2 minuten zeige, siehst du garnichts. Ich muss das Intervall für den Plot beschränken, liegen alle Striche übereinander

Du kannst dich gerne vom Gegenteil überzeugen.

 

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hilft jetzt wirklich weiter. Diese Ansicht wollte Guga ganz zu Anfang sehen!

Wie auch immer dein Konstrukt aussieht – es funktioniert, aber die Spurqualität könnte noch verbessert werden.
Dazu reicht es vielleiht aus, die Dynamik der Antriebe zu optimieren.
Oder die Taktung der neuen Positionen sollte ganze Vielfache von 2ms betragen – also 8ms oder 4ms.
Unter Umständen ist der Dynamik-Bereich auch schon ausgereizt – bei dem Informationsstand ist das nicht zu beurteilen.
Es ist auch nicht auszuschließen, dass die Motoren an ihrer Leistungsgrenze sind.

Ist die Mechanik leicht und Ruckfrei zu bewegen?

 

[herbi01]

Die Dynamikparameter sind noch nicht ausgereizt, werde mich morgen nochmals daran setzen. Ich überwache stets den Strom während des Überflugs und dieser ist noch weit unter dem nominal möglichen Output-Strom. Die Taktung der Positionsübermittlung werde ich sicherlich nochmals anschauen. Weiter werde ich die Parameter der Dynamik anpassen, bis das Ergebniss meinen wünschen entspricht. Das passiert in kleinen Schritten, aber ich sehe ein Ende.

 

[Chräshe]

Strom ist ein gutes Stichwort.
Ein Diagramm welches auch den Strom enthält, würde sehr helfen.

Mit welchem Tool erstellst du die Diagramme?

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Strom ist ein gutes Stichwort.
Ein Diagramm welches auch den Strom enthält, würde sehr helfen.

Mit welchem Tool erstellst du die Diagramme?

Ich glaube einem Beckhoff-Programmierer würde diese Frage nicht einfallen.

Da nimmst Du den integrierten kostenlosen TC-Scope und verbindest Dich auf die NC-Runtime über Port 501. Der Strom ist proportional zum Drehmoment. Wenn Du das nicht hast (Konfiguration nicht komplett), kann auch der Schleppabstand sehr aussagekräftig sein. Den hast Du immer zur Verfügung.

Ich möchte nochmal nach-betonen: Stichwort Schleppabstand (PosDiff)!

 

[Chräshe]

Ich glaube einem Beckhoff-Programmierer würde diese Frage nicht einfallen.

Da nimmst Du den integrierten kostenlosen TC-Scope und verbindest Dich auf die NC-Runtime über Port 501. Der Strom ist proportional zum Drehmoment. Wenn Du das nicht hast (Konfiguration nicht komplett), kann auch der Schleppabstand sehr aussagekräftig sein. Den hast Du immer zur Verfügung.

Ich möchte nochmal nach-betonen: Stichwort Schleppabstand (PosDiff)!

Der Schleppabstand entspricht indirekt (Sollwert – Istwert) und wurde bereits in Beitrag #4 gezeigt.

Allerdings kann man mit den Inkrementen ohne zusätzliche Infos nicht so viel anfangen.
Es fehlt der Bezug (Skalierung) zum verfahrenen Weg.
Deutlich besser wäre es, wenn alle Werte direkt aus der NC-Runtime in TC-Scope ermittelt werden.
Mir sieht das Diagramm nicht nach TC-Scope aus – jedoch bin ich mit TC3 auch nicht vertraut.

Wieso zeigst du plötzlich nur noch 45s, anstatt den 2 Minuten der vollständigen Nachführung?

Der Bereich zeigt sogar nur 5 Sekunden (beginnt bei 40s), jedoch scheinen die Antriebe die Differenz nicht einholen zu können.

 

[asci25]

Allerdings kann man mit den Inkrementen ohne zusätzliche Infos nicht so viel anfangen.
Es fehlt der Bezug (Skalierung) zum verfahrenen Weg.
Deutlich besser wäre es, wenn alle Werte direkt aus der NC-Runtime in TC-Scope ermittelt werden.

Ich habe nicht alles gelesen, doch der Schleppabstand wird in der Skalierung angezeigt - nicht in irgendwelchen Inkrementen.

Ich habe es mal überflogen.
Die Screenshots sind nicht vom TC-Scope.
Eigentlich wäre mal eine TwinCAT-Schulung nötig. Ich kann es z.Zt. leider nicht stemmen. Aber es scheint eine gewisse Menge Halbwissen im Raum zu liegen.

Nur soviel: Zuerst die NC-Achse richtig parametrieren und dann den TC-Scope nutzen. Zielsystem Port 501 NC-Runtime. Da findet man alle relevanten NC-Variablen. Dann im Lauf die Dynamik-Parameter richtig optimieren. So wird ein Schuh daraus.

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Welche Sollwert-Kurve wird an den Antrieb ausgegeben?
Wie kann der Sollwert im Antrieb davon abweichen?

Jetzt wird es klarer. Wenn die Werte nicht mit TC-Scope gelesen wurden, sondern mit irgendeinem anderen Tool, dann kann es sein, dass die Daten nicht aus einem Zyklus kommen.
Dann sind kleine Unterschiede normal!
Zur plausiblen Diagnose taugt das leider nur sehr bedingt...

 

[Cassandra]

@herbi01:
Gibt es neue Erkenntnisse?
Läuft inzwischen alles wie gewünscht?
Oder war Montag schon Abgabe und es ist jetzt sowieso egal?

 

[herbi01]

@herbi01:
Gibt es neue Erkenntnisse?
Läuft inzwischen alles wie gewünscht?
Oder war Montag schon Abgabe und es ist jetzt sowieso egal?

Hallo

ja habe das Problem grössten Teils in den Griff gekriegt. Jetzt gilt es noch einige kleine Dinge zu erledigen und den Bericht fertig zu stellen. Es lag grössten Teils an den dynamischen Parametern.

Gruss