S210 Positionierachse via TO steigt wegen Fehlberechnungen aus

L4s3r73k

Level-2
Beiträge
113
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen.

Rahmenbedingungen: S210 6SL3210-5HE1 FW 5.2.3. mit Singleturn Motor ohne Bremse 1FT2104-4AF0. CPU 1510SP-1 PN 6ES7 510-1DJ01-0AB0 mit Firmware 2.9.

Der Motor wird als Positionierachse via Technologieobjekt / MC Befehle V6 betrieben bis an seine Drehzahlgrenzen von +/- 8000rpm.
Dabei treten zwei erstmal ähnliche Phänomene auf.

1. Beim heraufbeschleunigen auf seine Maximaldrehzahl "kippt" die im Technologieobjekt berechnete Geschwindigkeit ins Negative um und somit die angenommene berechnete Position womit das Technologieobjekt einen Schleppfehler oder einen Positionierfehler macht. Die angenommene Position ist damit auch falsch was später meistens zur Kollision mit der Hardwareendlage führt.
Screenshot 2025-03-31 112003_Ist-Beschleunigungs&GeschwUmkehrBeiTopSpeedJog.png


2. Beim Hin- und Herpositionieren mit Geschwindigkeiten 75% < n < 95% (von 8000rpm) zeigen sich in der Auswirkung die gleichen Fehler, die Ursachen sind jedoch unterschiedlich und der Fehler lässt mitunter einige Minuten auf sich warten. Hier flackern "ActualVelocity" und "ActualAcceleration" und führen somit auch zu einem verfälschten Positionswert. Die Auswirkungen sind, wie bereits erwähnt, wie beim ersten Fehler. Der Fehler tritt auch bei wesentlich kleineren Geschwindigkeiten bis hin zur Nenndrehzahl 3000rpm auf, nur dauerte das im Test eher Stunden, bis das auftrat.

Screenshot 2025-03-31 115559_SpinnendeGeschw&Beschl.png



Observationen und Vermutung:
Bei beiden Fehlern gibt es keine Auffälligkeiten im Trace von G1_XIST1 Wert aus dem Antriebstelegramm.
Somit gehe ich davon aus, dass bei der CPU-Seitigen berechnung der Aktualdaten Rechenfehler auftreten, die einen irgendwie gearteten Überlauf zur Folge haben.
Somit wäre der Fehler bei Siemens zu suchen. Ticket ist auch bereits eröffnet. Die Frage ist, ob das bekannt ist?

Vielen Dank schonmal.
LG Dennis
 

Anhänge

  • Screenshot 2025-03-31 115559_SpinnendeGeschw&Beschl_2.png
    Screenshot 2025-03-31 115559_SpinnendeGeschw&Beschl_2.png
    180,5 KB · Aufrufe: 13
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielen Dank Mirko.
Ich bin dem Thema jetzt noch etwas mehr auf den Grund gegangen und habe, wie im verlinkten Thema mit den Taktzeiten vom Servo-OB gespielt.

  • Das Herabsetzen des Servotakts auf 1ms ließ provozierte den Fehler #2 praktisch ständig, sobald der Antrieb überhaupt lief – also eine Verschlechterung.
  • Das Heraufsetzen des Servotakts auf 8ms ließ den Fehler #1 bereits und rasch bei n>47% auslösen.
  • Das Heraufsetzen des Servotakts auf 16ms ließ den Fehler #1 bereits und rasch bei n>24% auslösen.

Also mit anderen Worten, heraufsetzen des Servotakts halbiert oder viertelt die Geschwindigkeit wo Fehler 1 auftritt, verringern zeigt das Phänomen von Fehler 2 bei geringerer Geschwindigkeit.

Kann es denn möglich sein, dass eine solch banale Aufgabe tatsächlich den IRT Bus braucht?
 
Was spricht gegen IRT?
Ohne bringt Dir der schnelle Zyklus ja gar nichts. Da tastet Du ja schneller ab als der Bus läuft. Dann bekommst Du z.B. zweimal den gleichen Lagewert bei zwei Abtastungen nacheinander was Geschwindigkeit 0 bedeutet...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Phänomen kenne ich ehrlich gesagt gar nicht und wir haben mit den S210 und TO auch sehr schnelle Kinematiken (Pick&Place) in Betrieb, teilweise 4 Kinematiken mit je 2 Motoren und 6 weitere S210.
Allerdings nutzen wir T-CPU und IRT.
Ich würde tatsächlich auch IRT vorschlagen. Wegen der Profinetverdrahtung hängen wir alle Servos an einen eigenen Port der SPS, da bekommt man mit der Topologie und IRT kein Problem. Ansonsten zuerst die Servos und dahinter alles andere anhängen.
 
@Mirko123
Die neueren S210 ab Firmware 6.3. können Einfachpositionierer. Unser S210 ist leider keiner davon.

@Ralle
Wir können uns hierzu gerne austauschen. Besonders interessant ist, ob du tatsächlich nicht die EPos Funktion der neueren S210 nutzt und welche Parameter genau wo eingestellt sind. Grundsätzlich arbeite ich hier ja zur Zeit mit einer ziemlichen Krücke (1510). Die aktuellen Forschungsergebnisse zu dem Thema gebe ich gerne Preis, vielleicht hilft es ja jemandem:

#########################################################################

Nachdem uns auch von Siemens zur Nutzung von Telegramm 5 und somit IRT geraten wurde, habe ich das Ganze entsprechend in die Tat umgesetzt. Ein erster Test verlief ernüchternd, da ich vergessen hatte, den MC_Servo von "Zyklisch" auf "Synchron zum Bus" einzustellen.
Screenshot 2025-04-02 105808_IRT_4ms_75%_Positionierfehler_Zyklisch.png
Ich machte mich auf die Suche nach funktionierenden Einstellungen aus einem Vorgängerprojekt. Diese führte mich auf entsprechende Einstellungen im MC_Servo unter "Synchron zum Bus": In einem Projekt vor nicht allzulanger Zeit hatte ich eine 1512 mit 5 Positionierachsen S210 und da stand Sendetakt 3ms und Faktor 2, was einen Applikationstakt von 6ms zur Folge hatte. Hier stieg das TO mit o.g. Fehler 1 wieder aus. Frustrierend, wenn ein an anderer Stelle bewährtes Programm aus nicht nachvollziebaren Gründen nicht funktioniert.
Weiterhin stieg irgendwann die CPU mit Zykluszeit 150ms aus - Sendetakt und Faktor waren beide 1, was wohl zu viel war für die CPU.

Weiterhin mit Fehler 1 stiegen aus Sendetakt 1ms und Faktor 4 und Faktor 8. Zur Erinnerung, der Fehler 1 sieht so aus:
Screenshot 2025-04-02 105808_IRT_94%_1msFkt4.png

Am Ende funktionieren Funktionieren taten Sendetakt 3 und Faktor 1 sowie Sendetakt 1 und Faktor 2.

Für diese Konstellation, diese CPU, Antrieb etc. pp.

Das ist nicht sehr befriedigend, aber ich denke wir werden diesbezüglich bald auf EPOS umsteigen.

Vielen Dank Leute.
 
Hallo zusammen,

ich möchte nochmals das Thema aufgreifen und für die Nachwelt Licht ins Dunkle bringen. Während der Ursachenforschung konnte der Mann von Siemens leider keine gescheitere Erklärung liefern als "nehmt doch IRT". Wir haben folgende Erklärung am Ende auch an Siemens geschickt, da kam dann aber keine Antwort mehr....

Kurzum, wir haben empirisch ermittelt, dass es mit IRT und einem Servo Applikationstakt von 1ms nicht geht, weil die kleine CPU in die Knie geht, mit 2 und 3 ms ging es dann und ab 4 ms ging es dann wieder nicht. Wohl sagend, dass wir die ganzen 8000 1/min des Motors nutzen wollen - ob das so gut ist oder nicht, ist die andere Frage. Wir haben nach einer mathematisch wissenschaftlichen Lösung gesucht und haben uns an das Abtasttheorem von Shannon Niquist erinnert. Demzufolge muss die Abtastfrequenz größer sein als 2 mal die maximal zu erwartende Frequenz. Der Motor macht 8000 U/min, was 133 U/s sind, was 133Hz sind und 7,5ms Periodendauer. Diese Frequenz multipliziert mit 2 ergibt 266Hz und 3,75ms. Mit dieser Argumentation wäre bewiesen, warum die 4ms nicht funktionieren können, aber die 3ms sehr wohl und gut funktionieren. 3ms sind 333Hz und da passen die 266Hz locker rein.

Gern Geschehen.
 
Zurück
Oben