S210 Antreib Absolutposition des Motors (Welle) nach referenzieren ermitteln

Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist ein Absolut Singleturn-Geber verbaut. Also gibt es schon eine eindeutige Zuordung Geber-Pos zur Motorwelle.
Wenn man aber jedesmal vor dem Fahren referenziert, erzeugt das mit der Zeit nen Fehler.
Nur um Missverständnisse auszuschließen, mit der Kommutierungslage hat das nichts zu tun (die wird beim Referenzieren auch nicht geändert).
Warum hier überhaupt referenziert werden soll, habe ich immer noch nicht verstanden, aber der Themenstarter möchte das ja unbedingt.
Gerne kann er ja den XIST1 auswerten, aber bei geeigneter Wahl der Spindelsteigung und Sollwertvorgabe sollte das nach meinem Verständnis lösbar sein. Da wären mal Screenshots interessant gewesen.
 
Ich hab auch ein ähnliches Problem.
Lösungsansatz von Siemens ist im Grunde eine Druckmarkenerkennung.
Also nach jedem Takt wird geguckt, ob ein Ini an dem Band/Produkt/Kette o.ä. vorhanden ist oder nicht (oder man nimmt den Ini als Messtaster und vergleicht den Messtaster mit der Position aus dem Antrieb) und dann beim nächsten Pos relativ wird mit Pos Superimposed + oder - z.B. 1mm positioniert.
Gibt auch eine Lib dazu: https://support.industry.siemens.com/cs/document/109475573/simatic-bibliothek-lprintmark-–-druckmarkenerfassung-mit-to-messtaster?dti=0&lc=de-WW
Das werde ich die nächsten Tage so testen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab auch ein ähnliches Problem.
Lösungsansatz von Siemens ist im Grunde eine Druckmarkenerkennung.
Also nach jedem Takt wird geguckt, ob ein Ini an dem Band/Produkt/Kette o.ä. vorhanden ist oder nicht (oder man nimmt den Ini als Messtaster und vergleicht den Messtaster mit der Position aus dem Antrieb) und dann beim nächsten Pos relativ wird mit Pos Superimposed + oder - z.B. 1mm positioniert.
Gibt auch eine Lib dazu: https://support.industry.siemens.com/cs/document/109475573/simatic-bibliothek-lprintmark-–-druckmarkenerfassung-mit-to-messtaster?dti=0&lc=de-WW
Das werde ich die nächsten Tage so testen.
Hier geht es um folgendes:
  • Schlupf zwischen Achse und Produkt
  • Walzenabnutzung
  • Materialfehler, Materialtoleranzen
  • ....
Beim Themenstarter tritt das angeblich nicht auf.
 
Laß sich für mich so, dass nach x Stunden die Position um x mm nicht mehr stimmt.
Daher wäre ich davon ausgegangen, dass man halt irgendwo Schlupf o.ä. hat, oder die mechanischen Daten (wie bei mir) nicht 100% ermitteln kann.

Hab das bei mir mit dem Pos superimposed auf jeden Fall jetzt so am laufen und korrigier jeden Takt um 0,1mm. Dadurch entsteht halt eine kleine Regelung.

Kann der TE ja auch so machen oder anders, war nur nen Vorschlag wie mans machen könnte.🤷‍♂️
 
Bin gerade auf Montage an einer anderen Anlage. Das Testen wird also noch etwas dauern.
Werde aber auf jeden Fall berichten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Daher wäre ich davon ausgegangen, dass man halt irgendwo Schlupf o.ä. hat, ...
Wenn bei jedem Positionieren zahlenmässig um einen kleinen Prozentsatz zuwenig positioniert wird, wäre Schlupf eine plausible Ursache.
Wenn der Schlupf überwiegend beim "Entschleunigen" passiert, kann es dazu führen, dass um einen kleinen Prozentsatz zuviel positioniert wird.
Wenn eine Über- bzw. Untersetzung im Spiel ist und die Berechnung der neuen ZielPosition "vereinfacht" wird, indem man einmalig den Quotienten der ZähneZahlen berechnet und als REAL- oder LREAL-Zahl abspeichert, um damit aus der Anzahl der gezählten "Striche" die neue Position auszurechnen, dann kann man auch einen Effekt beobachten, der sehr an Schlupf erinnert. Der ausgerechnete Quotient ist nicht genau genug und führt zu RundungsFehlern *). Je nach Ausführung der Mechanik kann realer Schlupf zusätzlich noch überlagert sein.

Welches Problem beim TE vorliegt bzw. von ihm beanstandet wird, kann ich aus seinen Beiträgen leider weiterhin nicht entnehmen. Ich warte noch mit Spannung auf die Auflösung ... ;)

*) Wieso konnte man früher mit RechenSchieber und LogarithmenTabellen klarkommen? Die Ansprüche an die Genauigkeit waren damals doch nicht so viel geringer? ;)
 
Es ist KEIN Schlupf...

Der "Fehler passiert beim Istwerverschieben!

Beispiel:
Die Verschiebung soll um einen Zahn passieren also z.B. 1/67 der Umrehung.
Die Geberauflösung ist 2048
Also um 30,567164179104477611940298507463 Inkremente

Da geht was verloren... Ich mache da niemandem einen Vorwurf, das ist nun mal so!

Deshalb der Ansatz die Absolute Position des Zahnrades zu bestimmen und dann den "Fehler" zu korriegieren.
Einen kleinen Fehler kann ich verschmerzen, wenn ich ihn nur über mehrere Verschiebungen wieder korriegiert bekomme.
 
Ich hab genau das selbe "Problem" gehabt, dass ich die ganz exakte mechanische Übersetzung nicht berechnen oder ermitteln kann.
Daher ist an das Zahnrad bzw. die Kette ein Ini gekommen, wenn nach einem Vorschub der Ini nicht da ist, dann mach ich im nächsten Schritt einmal einen pos superimposed mit +0,1mm und das ganz Spiel jeden Takt, also mit Ini vergleichen und dann +0mm oder +0,1mm. Fertig.
Du kannst ja auch einen Inkrementalgeber nehmen und dann das Zahnrad oder Kette oder Band was auch immer packen und dann den Geberwert mit dem Istwert aus deinem Antrieb vergleichen und verrechnen und dann halt um diesen Wert einen pos superimposed machen
Du darfst dann allerdings immer nur einen pos relativ machen, bei einem pos absolut wird vermutlich wieder ein Fehler entstehen. Der Geberwert im Antrieb läuft sowieso weg.
Du musst halt ermitteln wo deine Mechanik WIRKLICH steht und dann vergleichen und entsprechend korrigieren oder nicht und hierbei ist es in meinen Augen egal, ob du alle 5 Minuten korrigieren musst oder einmal Tag. Das ist halt das "Problem" von Vorschub Achsen, wenn du immer vor und zurück fährst hast du das Problem nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist KEIN Schlupf...
Keine Panik. Das ist doch längst angekommen.
Der "Fehler passiert beim Istwerverschieben!
Das ist mir nach wie vor nicht richtig klar.
Du versuchst also anscheinend Dein "MassBand" in einem gewissen Raster zu verschieben, aber leider passt das Raster nicht zum Geber, wie man aus dem folgenden Beispiel entnehmen kann.
Beispiel:
Die Verschiebung soll um einen Zahn passieren also z.B. 1/67 der Umrehung.
Die Geberauflösung ist 2048
Also um 30,567164179104477611940298507463 Inkremente
Da haben wir's doch:
2048 / 67 = 30,567164179104477611940298507463
Quotient aus GanzZahlen und Ergebnis als [L]REAL.
Was machst Du dann anschliessend noch mit der GleitKommaZahl?
Da geht was verloren... Ich mache da niemandem einen Vorwurf, das ist nun mal so!
Ja, da geht was verloren ... aber nur, wenn Du jetzt anfängst zu korriggieren und zurückliegende Positionierungen plattzumachen.
Deshalb der Ansatz die Absolute Position des Zahnrades zu bestimmen und dann den "Fehler" zu korriegieren.
Nicht korrigieren. Einfach nur runden. Und zwar jedesmals nach der Berechnung
2048 / 67 * AnzahlDerVerfahrenenStriche.
Die o.g. Anzahl der verfahrenen Schritte nicht korrigieren ("abschneiden"),sondern bei jeder Positionierung weiterführen
Einen kleinen Fehler kann ich verschmerzen, wenn ich ihn nur über mehrere Verschiebungen wieder korriegiert bekomme.
Du kannst sogar viele kleine Fehler verschmerzen. Nämlich, wenn Du alle Verschiebungen bzw. KorrekturVersuche nicht ausführst. Dann heben sich die Aufrundungen und Abrundungen (fast) auf.
In der Anzeige des aktuellen PositionsWertes subtrahierst Du noch die aufgelaufene Summe der "abgeschnittenen" Abschnitte.
Genauer kann ich das leider nicht angeben, weil ich - wie anfangs gesagt - immer noch nicht verstanden habe, was und wie Du da genau meinst korrigieren zu müssen.
 
Es ist KEIN Schlupf...

Der "Fehler passiert beim Istwerverschieben!

Beispiel:
Die Verschiebung soll um einen Zahn passieren also z.B. 1/67 der Umrehung.
Die Geberauflösung ist 2048
Also um 30,567164179104477611940298507463 Inkremente

Da geht was verloren... Ich mache da niemandem einen Vorwurf, das ist nun mal so!

Was hast Du als Spindelsteigung eingestellt?
 
Zurück
Oben