Spiel Problematik bei Rast-Schnecken

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Spiel Problematik bei Rast-Schnecken

Beitrag von jomifa » 10 Jun 2020, 10:35

Hallo zusammen,
ich habe einen 3-achsigen Roboter, der auf der X-Achse über einen Encodermotor seine Kraft über ein Rastketten-Rad Z20 (137 677), 2 Rast-Ritzel Z10 (35 945), einer Rastschnecke (35 072) auf einen Drehkranz (31 390) überträgt. Aus ft Sicht eine ganz normale Vorgehensweise für deren Modelle. Das Problem, welches ich habe, ist, dass mir der auftretende Schlupf durch die Rast-Schnecke in beiden Richtungen unterschiedlich groß ist. Kann also Software-technisch nicht korrigiert werden. Ich möchte so wenig Schlupf wie möglich, da es bei der Positionierung der X-Achse auf jeden Drehimpuls vom Encodermotor ankommt. Ein Drehimpuls wäre als Ungenauigkeit ok. Jetzt liegt mir ein Schlupf in der Größenordnung zwischen 3 und 5 Drehimpulsen vor. Der Encodermotor und der Drehkranz können nicht verändert werden. Alle Teile dazwischen stehen zur Disposition. Sie dürfen nur nicht über dem Platzbedarf der beschriebenen Lösung hinausgehen.

Was habt ihr für Ideen, wie ich das Problem beseitigen könnte.

Grüße,
Jaochim
Zuletzt geändert von jomifa am 12 Jun 2020, 16:38, insgesamt 2-mal geändert.

Benutzeravatar
uffi
Beiträge: 404
Registriert: 24 Jan 2014, 16:21
Wohnort: München

Re: Schlupf Problematik

Beitrag von uffi » 10 Jun 2020, 15:38

Hallo Joachim,

ich denke es handelt sich bei den 3-5 Zählimpulsen nicht um einen Schlupf, sondern um das normale Getriebespiel. Dieses ist sehr wohl in SW korrigierbar, das Vorgehen ist wie folgt:

- bei jedem Richtungswechsel der Drehrichtung des Motors, und nur dann, gibst Du 4 Zählimpulse dazu zur Zielvorgabe. Dann wird das Spiel ausgeglichen und Du hast die gewünschte Genauigkeit von 1 Zählimpuls.

Da sich die Ungenauigkeit von 1 Zählimpuls pro Positionsanfahrt aber mit der Anzahl der Richtungswechsel aufaddiert, kannst Du z.B. alle 4 Richtungswechsel wieder den Initialpunkt zur Kalibrierung anfahren.

Gruß, Dirk

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 10 Jun 2020, 17:06

Hallo DIrk,
damit ich das richtig verstehe ein Beispiel:

--10----->--4>
<--5- (+4)
<--3
-----9-->
(+4)

Das würde bedeuten, dass ich +8 Drehimpulse zu der gefahrenen Strecke von 15 Drehimpulse dazugeben müsste, wenn ich die erreichte Position neu vom Referenzpunkt (0) aus anfahren würde. (15+8=23).

Gruß,
Joachim

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Schlupf Problematik

Beitrag von fishfriend » 10 Jun 2020, 17:53

Hallo...
Alleine das Stoppen des Motors ist größer (und hat je nach dem wie man das macht).
Stell dir mal vor wenn der Magnet relativ nahe am Sensor ist. Dann kann es sein das er zählt obwohl der sich nicht bewegt.
Wenn es wirklich um jeden Impuls geht, würde ich noch eine 10:1 dazumachen. Dann hast du weniger Spiel.

Was für ein Projekt machst du, dass du eine so hohe Genauigkeit brauchst?

Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Schlupf Problematik

Beitrag von hamlet » 10 Jun 2020, 18:22

Hallo Joachim,
schau mal hier:
viewtopic.php?f=6&t=4777&p=34750#p34721
... Eventuell ein Artikel über den RoboPro-Encoder-Positionierer mit Umlauf und Spielausgleich? ...
Leider hab ich einen ftpedia Artikel nie verfasst, aber ich habe versucht die rpp-Library sauber zu dokumentieren ...
Grüße,
Helmut
Zuletzt geändert von hamlet am 11 Jun 2020, 19:23, insgesamt 1-mal geändert.

Benutzeravatar
uffi
Beiträge: 404
Registriert: 24 Jan 2014, 16:21
Wohnort: München

Re: Schlupf Problematik

Beitrag von uffi » 10 Jun 2020, 18:24

Hallo Joachim,

Das als Beispiel gezeigte Schema passt für mich, so hatte ich das gemeint.
Nur Deinen letzten Satz verstehe ich nicht: wenn Du eine Position direkt vom Regerenzpunkt anfährst, musst Du meiner Meinung nach gar nichts zugeben, da Du keinen Richtungswechsel hast.

Gruß, Dirk

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 10 Jun 2020, 19:09

Vielen Dank für eure Antworten.

@Dirk @Holger
Ich bin gerade dabei die Fabrik Simulation mit 2 Joysticks zu versehen, um die entsprechenden Lade-/Entladepositionen zu kalibrieren. Zurzeit ist das alles im Programm hard coded und alle Änderungen sind dort vorzunehmen. Das möchte ich dahingehend verändern, dass ich die genauen Positionen mittels Joysticks online positionieren möchte, um sie dann im TXT abzuspeichern. Das Modell liest dann bei jedem Neustart der Anlage diese Werte aus. Das bedeutet, dass du bei der Kalibrierung eine bestimmte Position von der Referenzposition aus anfährst und anschließend mit den Joysticks die Feinkalibrierung machst. Anschließend wird die Kalibrierung durch zurückfahren auf die Referenzposition und anschließender Einnahme der neuen Position verifiziert. Dabei fehlen mir in der Regel 3 bis 5 Drehimpulse. Praktisch kannst du auch von der Referenzposition mittels Joysticks die neue Position anfahren. Eine Kontrolle der Rast-Schnecke ergab, dass beim Starten des Motors besagten 3 bis 5 Drehimpulse vom Endodermotor erzeugt werden, ohne dass sich die Rast-Schnecke dreht. Dies geschieht allerdings nicht in jeder Laufrichtung des Encodermotors. Bei den anderen Achsen, wo mit Schneckenmuttern und Schnecken gearbeitet wird, habe ich dieses Problem nicht.

@Helmut
Das RoboPro Programm muss ich mir einmal in Ruhe anschauen. Du rechnest ja viel in diesem Programm. Vielen Dank dafür.

Gruß
Joachim

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Schlupf Problematik

Beitrag von fishfriend » 10 Jun 2020, 22:25

Hallo...
Ich gebe zu, dass ich vermute in welche Richtung das geht. Ich bin mir aber nicht sicher.
Spontan würde ich jetzt sagen es ist ein Lastproblem.
In der Anleitung zum ftduino steht auch was zum Bremsen eines Motors drin (aktiver Kurzschluss).
Aber auch da ist immer eine Unsicherheit drin. Alleine die Massenträgheit bei verschiedenen Geschwindigkeiten bis hin zum Querschnit der Zuleitung oder die Belastbarkeit der Spannungsquelle (z.B. wieviele Motoren gleichzeitig laufen - oder Spannung rückspeisen, je nachdem wie das angeschlossen ist).
Ich würde immer von einem Bereich ausgehen wo der Motor stoppt. Dazu kommt dann noch die Drift - Nie ein Punkt mit dem Wellenmagneten.
So aus der Praxis, fährt ein Roboter oder ft-Modell in einen Taster rein und dann wieder raus um einen Referenzpunkt zu bekommen. Da würde auch der Richtungswechsel kompensiert, da er nur Richtung weg vom Taster fahren kann. Die ganzen Impulse zum Spiel im Getriebe fallen raus.
Genau da würde ich den Referenzpunkt der "genauen" ablage machen. Nur die Aufnahme hat dann "etwas" Spiel. Das Objekt wird dann unsauberer gegriffen.
Umgangen wird das Ganze auch mit Führungen (Winkelbausteinen) wo das Objekt etwas zur Seite geschoben wird.
Ich wundere mich aber dennoch. Wenn ich mir die ft Modelle wie Plotter oder meine Fraäse anschaue komme ich locker auf geschätze 1/10.
Deswegen -vermute- ich ein anderes Problem.
Mit freundlichen Grüßen
fishfriend
Holger Howey
BTW Kannst du mal ein Foto davon machen. Welches sind denn die "anderen" Achsen die kein Problem machen?
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 10 Jun 2020, 23:02

Hallo Holger,
ich vertraue auf den Encoder des Motors. Wenn ich sage fahre 10 Drehimpulse fährt der Motor 10 Drehimpulse unabhängig einer bestehenden Last. Er braucht dazu vielleicht einmal länger oder kürzer. Aber er dreht 10 Drehimpulse. Und wenn die anzufahrenden Koordinaten einmal stimmen, dann fährt er von der Referenzposition mehr oder weniger immer gleich weit. Das anfängliche Spiel beim Start des Motors kann vernachlässigt werden. Nicht aber, wenn ich die einzunehmenden Koordinaten erst durch die Ansteuerung über den Joystick ermitteln muss. Das geht dann nur in Teilstücken (vor, zurück, hoch oder runter bis es passt) zu machen. Die Addition dieser Teilstücke muss dann beim Anfahren der Koordinaten nach der Einnahme der Referenzposition korrekt sein.

Welches Problem vermutest du denn?

Bitte nicht wundern über die vielen Endtaster (4 pro Achse). Die inneren zwei sind für das RoboPro Programm und die äußeren zwei für eine externe Überwachung der Achsen). Ich hasse es, wenn Motoren durch Programmfehler oder TXT Macken ihre Endpositionen überfahren wollen. Das ist in meinem Modell nicht möglich.

Gruß
Joachim
Dateianhänge
Y-Achse
Y-Achse
IMG_4026.jpg (104.63 KiB) 6769 mal betrachtet
Z-Achse (Spiel ausgeglichen durch Unterlegscheiben, rechts)
Z-Achse (Spiel ausgeglichen durch Unterlegscheiben, rechts)
IMG_4025.jpg (123.74 KiB) 6769 mal betrachtet

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Schlupf Problematik

Beitrag von fishfriend » 11 Jun 2020, 16:46

Hallo...
Nachfrage, woher kommen die -10- "Impulse"?
Der Encodermotor, je nachdem welche man hat, machen zB. 75 Impule pro einer Umdrehung.
Bei 10 Impulsen sind das 48° bei der Motorwelle. Sieht man da echt eine Bewegung am Drehkranz (oder ist es die Z-Achse)? Du hast ja noch eine weitere Untersetzung dazwischen. Gibt es da noch einen Taster dafür oder nimmst du den Encoder?

Ich bin da gerade etwas mehr in dem Thema drin, weil ich diese Imulssteuerung (Counter) auf den ftduino mit RoboPro umgesetzt habe.
Wenn du dir mal das kleinere ft-Modell Hochregallager anschaust, da wird immer der Taster angefahren und dann raus.
Die Steuerung läuft intern über den TX/TXT. Der Regelt / Zählt das nicht RoboPro. Wenn man z.B. die Tonnen nun von links nach rechts setzen würde, ohne in den Nullpunkt zu fahren, kommt es auch zu ungenauigkeiten.

Evtl. Kann ja der Motor, nach der Änderung über den Joystick, erst wieder in den Taster und raus fahren. Man würde dann nicht direckt den Punkt ändern sondern nur den internen Wert um jew. 1 hochzählen.
Noch andere Idee: Einen Schrittmotor nehmen.

Irgendwie kann ich immer noch nicht glauben das es soo Ungenau sein soll.
Kannst du noch mal von der anderen Seite Fotos machen?

Mit freundlichen Grüßen
fishfriend
Holger Howey
Noch ein Tipp. Bau den Motor aus oder nimm das Ritzel ab und lass den mal 5 Minuten volle pulle in beide Rchtungen laufen. Wenn der zum Ende langsamer werden sollte solange machen, bis der gleich läuft.
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 11 Jun 2020, 18:42

Hallo Holger,
die 10 Impulse gebe ich im RoboPro Programm an. Wenn sie erreicht worden sind, dann bleibt der Motor stehen.

Ich habe ein Test Programm was einfach 10-mal einen Drehimpuls aus der Nullposition herausfährt. Fahre ich diese 10 Einzeldrehimpulse wieder zurück, fehlen mir ca. 3 Drehimpulse zur Nullposition (ca. 2mm). Das liegt daran, dass sich die Rastschnecke erst beim 3. Drehimpuls zu drehen beginnt. Wenn man sich in dieser Zeit das Z20 und die Rast-Schnecke ansieht, dann sieht man ganz genau, dass erst bei dem 3-ten Drehimpuls die Rast-Schnecke und damit auch der Drehkranz bewegt wird. Das bedeutet, dass Fahrstrecke und Drehimpulsangaben nicht übereinstimmen. Ergo handelt es sich hier um ein mechanisches Problem! Das Problem ist, wie bekomme ich das Spiel aus der Rast-Schnecke raus und warum bewegt sich diese Schnecke erst nach 3 Drehimpulsen. Die Zahnräder Z20/Z10 übertragen die Kraft des Motors auf die Achse der Rast-Schnecke. Es ist deutlich zu sehen, dass sich alle Zahnräder gemäß des Drehimpulses drehen aber nicht die Rast-Schnecke. Ich denke, dass eine Verwindung im Bereich der Rast-Achse und Rast-Kupplung zur Rast-Schnecke vorliegt (Plastik-Achse), die das Drehen der Schnecke in dieser Position verhindert.


Generelles:
Das sich diese Art von ft Modelle zwischen den einzelnen Fahrten immer neu positionieren (Referenzfahrt gegen den Taster) müssen versteht sich dann von selbst. Täten sie das nicht, wären sie in kürzester Zeit aus dem Ruder gelaufen.

Anmerkungen:
Zu deinen Anmerkungen bezüglich Volllast des Motors: Der Motor dreht in beiden Richtungen laut Angabe des Interface gleich viele Umdrehungen. Ich habe ein Programm, welches mit Hilfe eines Lasers die Drehimpulse pro Umdrehung misst. Dabei ist mir aufgefallen, dass Encodermotoren einer bestimmten Marge nicht die vorgeschriebenen Impulse von 63 1/3 erreichen.

Gruß,
Joachim
Dateianhänge
Test Laser-Impulsmessmodul für Encoder Motoren #1.JPG
Test Laser-Impulsmessmodul für Encoder Motoren #1.JPG (107.16 KiB) 6676 mal betrachtet

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Schlupf Problematik

Beitrag von hamlet » 11 Jun 2020, 19:11

Hallo Joachim,
Wenn Dein Aufbau so schwergängig ist, dass sich die Achsen verwinden wird eine Korrektur in Software schwierig.
Ich hab eben mal die Verbindung von Rastschnecke zu Rast Achse geprüft: Die kann recht großes Spiel haben. Vielleicht ist es das. Das kannst Du beim Richtungswechsel korrigieren.
Der oben verlinkte Positionierer macht genau das. Er fährt auch neue Positionen basierend auf der zuletzt gemessenen Position an, die sich ja manchmal um ein oder zwei Tics von angeforderten Distanz unterscheiden kann, wenn man zu rabiat ansteuert. So sollten sich die Fehler nicht fortpflanzen.
Grüße,
Helmut

EDIT: Ich habe obigen Link aktualisiert, ... ein kleiner Fehler weniger
https://1drv.ms/u/s!AjSvbnB4EKxJmRfpAb2 ... r?e=jTT4dE

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: Schlupf Problematik

Beitrag von Karl » 11 Jun 2020, 20:45

Hallo,
waren da nicht schon mal Problemchen mit den Encoder-Motoren ?
Da war es bestimmt der "Rote Teufel".
viewtopic.php?f=8&t=5874

Benutzeravatar
fishfriend
Beiträge: 1793
Registriert: 26 Nov 2010, 11:45

Re: Schlupf Problematik

Beitrag von fishfriend » 11 Jun 2020, 22:23

Hallo...
Was mir noch einfällt...

Der Ablauf wartet ja im RoboPro Programm bist der TXT meldet das er damit fertig ist. Es ist also der Counter im TXT.
Nun könnte der auch der Geber im Motor "etwas" prellen oder halt wie gesagt die Endpositionen.
Der Motor selber hat ja auch ein Getriebe - das wiederum Spiel hat.

Ok mal zur Rastschnecke. Die hat auch "Spiel" zu den Zähnen. Meist ist der Abstand entscheident.

Schau doch mal was er macht wenn du die Geschwindigkeit runter setzt. Evtl. muss man zum Ende hin die Geschwindigkeit über eine Rampe verringern. Der Aufwand dazu ist sehr Groß - der Erfolg fraglich. Das könnte sogar in die Größenordnung Spiel der Bausteine je nach Produktion gehen.

Ich könnte mir auch Vorstellen das die (?) Zahnräder nicht Mittig auf der Achse sind. Jedoch sollten die Positionen, da es kein Umlauf ist, gleich sein.
Bleibt für mich 1. die Masse (trägheit) und 2. Erdanziehung. 2. deshalb weil ich letztens mit dem Hochregallager mit dem Encodermotor überrascht war das beim Umsetzen der Tonnen unterschiedliche Höhenwerte da waren (mehr als 10 Impulse).

Ich vermute jetzt das es ehr schon eine Drift des TX/TXT sein könnte. Selbst wenn man einen ganz anderen Geber mit absoluter Position hättest, sind +-3 Impulse beim ft-Motor nicht viel. Bei 100 mal hin und her ohne Nullen dann schon. Na ja aber das hilft auch nicht wirklich weiter.

Gummi zwische Achse und Zahnrad (Spiel Achse Zahnrad). Das nächste was ich probieren würde, ist Silikonspray.
Ich überleg mal weiter...
Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 12 Jun 2020, 00:50

Hallo zusammen,

@Helmut
Ich hab eben mal die Verbindung von Rastschnecke zu Rast Achse geprüft: Die kann recht großes Spiel haben. Vielleicht ist es das.
Genau so sehen ich das auch. Ich habe mal das Z20 Ritzel abgemacht und das am Ende der Rastachse sitzende Z10 mit Daumen und Zeigefinger ohne Probleme drehen können. Ich würde noch nicht einmal sagen, dass es schwergängig ging.
Allerdings erschließt sich mir das von dir erwähnte Programm nicht so richtig. Ziemlich viel Aufwand, um das Spiel der Rast-Schnecke ausgleichen zu wollen. Vielleicht kannst du mir mehr zu deinem Programm sagen, gerne auch offline.

@Holger
Das Anfahren aus der Null Position heraus auf eine bestimmte Position klappt natürlich immer, weil dann das immer existierende Spiel beim Anfahren vorhanden ist und damit keine Rolle spielt. Aber Richtungswechsel während der Findung der zu erreichenden Position mittels z.B.: Joysticks macht das Problem aus.

@Dirk
Ich habe deinen Vorschlag einmal programmiert. Bei einem Richtungswechsel und einem Spiel von 2 Drehimpulsen hat das ganz gut hingehauen. Wenn ich allerdings die zu fahrenden Teilstrecken in der Länge variiere, bekam ich schon wieder ganz unterschiedliche Ergebnisse.


Grüße,
Joachim

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Schlupf Problematik

Beitrag von hamlet » 12 Jun 2020, 08:16

Hallo Joachim,
Bei dem Programm handelt es sich um eine universell einsetzbare Library zur Encodermotor-Positionierung. Ich habe sie damals geschrieben um die Komplexität der Positionierung aus meinem eigentlichen Programm rauszuhalten. Meines Wissens gab es damals keine entsprechende Library mit dem Funktionsumfang:
  • Die Positionierung jedes Motors läuft auf einem eigenen unabhängigen Prozess. Die Positionierungen können gleichzeitig zueinander und gleichzeitig zum Hauptprogramm erfolgen.
  • Das Interface ist einfach und entspricht der erweiterten Robopro Motorsteuerung: "Positionsanforderung" und "Warten auf Positionierung"
  • Automatischer Spielausgleich bei Richtungsänderungen
  • Keine Fortpflanzung kleiner Positionsfehler, wenn der Encoder mal einen Encoder-Tic zu weit gefahren ist, da weitere Positionierungen stets basierend auf der gemessenen Position erfolgen.
  • Umlauf-Positionierung von Drehtischen: Die Library wählt automatisch den kürzesten Weg zur Zielposition. Das war ganz schön tricky und hat den Algorithmus kompliziert gemacht. Brauchte ich aber um die Komplexität aus dem die Library verwendenden Programm rauszuhalten.
  • Sauberes Anfahren des Nullpositionsschalters mit separat wählbarer langsamer Geschwindigkeit. Hierbei ist zu beachten, dass die Encoder-Frequenz bis zu 400Hz beträgt und die Sampling-Frequenz des TX/TXT Universaleingänge bei lediglich 100Hz liegt.
  • Der Nullpositionsschalter lässt sich mit einem Offset virtuell verschieben. Man kann ihn so an beliebiger Stelle ins Modell bauen. Die Library kommt auch mit negativen Positionen zurecht.
    Bei linearer Positionierung ohne Umlauf muss man da aber ein bisschen aufpassen: Bei der Initialisierung geht die Library davon aus, dass sie im positiven Positionsbereich ist. Falls dem nicht so ist, sucht sie die Nullposition in der falschen Richtung und es kracht.
    Ich hatte das feature für kleine Korrekturen eingebaut, um mir die mechanische Justage des Schalters zu ersparen. Bei positiver Korrektur oder wenn der Schalter bei negativer Korrektur gedrückt bleibt, ist die Verwendung dieser Funktion sicher.
Grüße,
Helmut

Anbei die Dokumentation aus der Library:

Code: Alles auswählen

Encoder Motor position controller
Performs the position control on its own independent process. Place one controller per motor in your main program or where you need it.
Provides circular control e.g. of turntables. Automatically selects direction with shortest distance to target position in circular mode.
Compensates backlash when motor direction changes.

Inputs:
ID:          ID of the motor controller: [0..15]. Used in interface functions "MiP",MiE" and MiP" for addressing the motor controller
V:           Standard fast PWM speed applied for positioning,[-512..512] or [-8..8] depending on the setting in RoboPro's motor output. 
              ... Sometimes it's easier just to change the sign/direction of V than swapping wires in the model.
v :           Slow speed used for zero position initialization,  [1..512] or [1..8] Has to be positive, as the controller aligns the direction with V automatically.
              Shall be not too fast. Keep in mind that the zero position switch universal inputs are sampled at 100Hz and on the TXT sometimes even slower.
ZO:         Zero Offset. This parameter virtually moves the origin switch. See also below: "Zero Position Initialization"
CD:         Circular distance: Number of encoder ticks for one revolution in circular mode. 
              For linear mode, i.e. non circular, just set it to zero or choose a reosonable large value e.g. 2^15-1=32767 (largest RoboPro integer)
BL:         Backlash measured in encoder ticks. See "Backlash" below
ME:        Connect RoboPro's "Position Reached" input here.
MC:        Connect RoboPro's corresponding "Counter Input" here.
OS:        Origin Switch: Connect RoboPro's zero position switch input here. Digitally ohmic, closed (true) when pressed.

Output:
M:          Connect RoboPro's motor output here.


Interface functions:
MiP (two inputs)      Sends a position request to the selected motor controller. Proceeds in process, when the controller starts to execute the request.
                              If the motor controller is still busy with a prior request, this function blocks until the prior request is processed.
                              Accepts negative positions too.
MiP (one input)        Returns the position of the selected motor controller. The position is updated, when the position has been reached.
                              The returned position is the measured position and might be slightly different from the requested one.
                              It might get negative: [-CD .. CD]
MiE                        Waits until the selected controller (index 0..15) has reached the requested position.
MbE                       Waits until the selected controllers (bitmap) have reached their requested positions, e.g. 0b101 for motors with indices 0 and 2.       
 
Zero Position Initialization:
The zero position initialization is performed each time a position request with position=0 is sent to the controller.
The very first initialization is performed before the first position request is executed, independently of the target position set in the first request.
The controller moves with fast speed into direction of the origin switch until it is pressed.
In cyclic mode the controller selects direction with shortest distance. In linear mode or for the very first initialization it uses -V. 
Then it drives the motor with low speed "v" in positive direction until the origin switch opens. This is the reference position.
"v" should be reasonably slow, as the zero position switch universal inputs are sampled at 100Hz and on the TXT sometimes even slower.
Then the controller positions the motor to the zero offset "ZO" position, if set. This is position "0".

Backlash:
A simple method to estimate the mechanical backlash:
Open the test interface and select the 512 step speed selection for the motor. 
Adjust the speed to a very low value, that's just sufficient to start the motor and to overcome the mechanical friction of the free backlash travel, 
but that's too low to fully drive the mechanics, so that the motor comes to a stall after the free backlash travel.
Move the motor at this speed back and forth and read the number of backlash ticks form the counter input.

Implementation:
The global list "m_rdy","m_pos" and "m_set" are used for communication with the interface functions.
Sequence:
* Starts the process, waits some time and set the ready flag in "M_rdy" to true.
* Then it waits for position requests, i.e. until the ready flag is reset to false by "MiP".
* Calculates the distance and direction by calling "Mclc". 
* If distance is zero and controller is initialized, do nothing.
* If requested position id isn't zero and controller is initialized, enters the normal position sequence on the right.
* In the other case, either position is zero or the controller isn't initialized yet, it enters the zero position sequence on the lower left side.
  After this it checks the requested position and enters the regular position sequence if needed.
* When done it sets the ready flag to true and waits for new requests.
Und nochmal google-übersetzt. Klingt teilweise ein wenig blumig, was evtl. auch an meinem Englisch liegt:

Code: Alles auswählen

Encoder Motorpositionsregler
Führt die Positionssteuerung in einem eigenen unabhängigen Prozess durch. Platzieren Sie einen Controller pro Motor in Ihrem Hauptprogramm oder dort, wo Sie ihn benötigen.
Bietet kreisförmige Kontrolle, z. von Plattenspielern. Wählt im kreisförmigen Modus automatisch die Richtung mit dem kürzesten Abstand zur Zielposition aus.
Kompensiert das Spiel, wenn sich die Motorrichtung ändert.

Eingaben:
ID: ID der Motorsteuerung: [0..15]. Wird in den Schnittstellenfunktionen "MiP", MiE "und MiP" zur Adressierung der Motorsteuerung verwendet
V: Standardmäßige schnelle PWM-Geschwindigkeit für die Positionierung, [- 512..512] oder [-8..8], abhängig von der Einstellung der Motorleistung von RoboPro. ... Manchmal ist es einfacher, nur das Vorzeichen / die Richtung von V zu ändern, als die Drähte im Modell auszutauschen.
v: Langsame Geschwindigkeit für die Initialisierung der Nullposition, [1..512] oder [1..8] Muss positiv sein, da der Regler die Richtung automatisch auf V ausrichtet.
              Soll nicht zu schnell sein. Beachten Sie, dass die Universaleingänge des Nullstellungsschalters mit 100 Hz und auf dem TXT manchmal sogar langsamer abgetastet werden.
ZO: Nullpunktverschiebung. Dieser Parameter bewegt den Ursprungsschalter virtuell. Siehe auch unten: "Nullpositionsinitialisierung"
CD: Kreisabstand: Anzahl der Encoder-Ticks für eine Umdrehung im Kreismodus.
              Für den linearen Modus, d. H. Nicht kreisförmig, setzen Sie ihn einfach auf Null oder wählen Sie einen wiederverwendbaren großen Wert, z. 2 ^ 15-1 = 32767 (größte RoboPro-Ganzzahl)
BL: Spiel gemessen in Encoder-Ticks. Siehe "Spiel" unten
ME: Verbinden Sie hier den Eingang "Position erreicht" von RoboPro.
MC: Schließen Sie hier den entsprechenden "Zählereingang" von RoboPro an.
Betriebssystem: Ursprungsschalter: Schließen Sie hier den Eingang des RoboPro-Nullstellungsschalters an. Digital ohmsch, geschlossen (wahr) beim Drücken.

Ausgabe:
M: Schließen Sie hier den Motorausgang von RoboPro an.


Schnittstellenfunktionen:
MiP (zwei Eingänge) Sendet eine Positionsanforderung an die ausgewählte Motorsteuerung. Fährt fort, wenn der Controller beginnt, die Anforderung auszuführen.
                              Wenn die Motorsteuerung noch mit einer vorherigen Anforderung beschäftigt ist, wird diese Funktion blockiert, bis die vorherige Anforderung verarbeitet wurde.
                              Akzeptiert auch negative Positionen.
MiP (ein Eingang) Gibt die Position der ausgewählten Motorsteuerung zurück. Die Position wird aktualisiert, wenn die Position erreicht wurde.
                              Die zurückgegebene Position ist die gemessene Position und kann geringfügig von der angeforderten Position abweichen.
                              Es könnte negativ werden: [-CD .. CD]
MiE Wartet, bis der ausgewählte Controller (Index 0..15) die angeforderte Position erreicht hat.
MbE Wartet, bis die ausgewählten Controller (Bitmap) ihre angeforderten Positionen erreicht haben, z. 0b101 für Motoren mit den Indizes 0 und 2.
 
Initialisierung der Nullposition:
Die Nullpositionsinitialisierung wird jedes Mal durchgeführt, wenn eine Positionsanforderung mit Position = 0 an die Steuerung gesendet wird.
Die allererste Initialisierung wird durchgeführt, bevor die erste Positionsanforderung ausgeführt wird, unabhängig von der in der ersten Anforderung festgelegten Zielposition.
Der Regler bewegt sich mit hoher Geschwindigkeit in Richtung des Ursprungsschalters, bis er gedrückt wird.
Im zyklischen Modus wählt die Steuerung die Richtung mit der kürzesten Entfernung. Im linearen Modus oder für die allererste Initialisierung wird -V verwendet.
Dann treibt es den Motor mit niedriger Drehzahl "v" in positiver Richtung an, bis der Ursprungsschalter öffnet. Dies ist die Referenzposition.
"v" sollte relativ langsam sein, da die Universaleingänge des Nullstellungsschalters mit 100 Hz und auf dem TXT manchmal sogar langsamer abgetastet werden.
Dann positioniert die Steuerung den Motor auf die Nullpunktverschiebung "ZO", falls eingestellt. Dies ist Position "0".

Rückschlag:
Eine einfache Methode zur Abschätzung des mechanischen Spiels:
Öffnen Sie die Testschnittstelle und wählen Sie die 512-Schrittdrehzahl für den Motor.
Stellen Sie die Drehzahl auf einen sehr niedrigen Wert ein, der gerade ausreicht, um den Motor zu starten und die mechanische Reibung des freien Spielwegs zu überwinden.
aber das ist zu niedrig, um die Mechanik vollständig anzutreiben, so dass der Motor nach dem freien Spielweg zum Stillstand kommt.
Bewegen Sie den Motor mit dieser Geschwindigkeit hin und her und lesen Sie die Anzahl der Spielhaken am Zählereingang ab.

Implementierung:
Die globalen Listen "m_rdy", "m_pos" und "m_set" werden für die Kommunikation mit den Schnittstellenfunktionen verwendet.
Reihenfolge:
* Startet den Prozess, wartet einige Zeit und setzt das Ready-Flag in "M_rdy" auf true.
* Dann wartet es auf Positionsanforderungen, d. H. Bis das Bereitschaftsflag von "MiP" auf false zurückgesetzt wird.
* Berechnet die Entfernung und Richtung durch Aufrufen von "Mclc".
* Wenn der Abstand Null ist und der Controller initialisiert ist, tun Sie nichts.
* Wenn die angeforderte Positions-ID nicht Null ist und der Controller initialisiert wird, wird die normale Positionssequenz rechts eingegeben.
* Im anderen Fall ist entweder die Position Null oder der Controller ist noch nicht initialisiert. Er gibt die Nullpositionssequenz unten links ein.
   Danach überprüft es die angeforderte Position und gibt gegebenenfalls die reguläre Positionssequenz ein

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 12 Jun 2020, 12:10

Hallo Helmut,
vielen Dank noch einmal für deine Ausführungen.

Ich habe dein Programm erst einmal so angepasst, dass ich einen ersten Eindruck von seiner Lauffähigkeit bekomme. Dabei viel mir auf, dass die Eingabeschreibung für ICH bzw. ME in der Beschreibung differieren. Im Programm nennst du die Eingabe ME und in der Doku ICH. Ist vielleicht nur ein Doku Fehler.

Deine Messmethode, um das Spiel herauszubekommen, hat meine Vorgehensweise der Spielermittlung bestätigt.


Jetzt zum Ablauf:

Ich habe den Motor (M1) im ersten Schritt auf die 0 Position gesetzt, um dann anschließend 50 Drehimpulse zu fahren. Das Programm bleibt aber nach Einnahme der 0-Position (Freigabe des Tasters I1) stehen. Warum im Zählerfenster des Interface der Wert 30 steht ist mir auch unklar. Ich habe die Situation durch screen shots einmal dokumentiert.

What’s going wrong? Oder vielleicht habe ich noch das anfängliche Setup nicht korrekt verstanden.

Gruß,
Joachim
Dateianhänge
Ablauf #4.JPG
Ablauf #4.JPG (48.1 KiB) 6499 mal betrachtet
Ablauf #3.JPG
Ablauf #3.JPG (122.5 KiB) 6499 mal betrachtet
Ablauf #2.JPG
Ablauf #2.JPG (59.89 KiB) 6499 mal betrachtet
Ablauf #1.JPG
Ablauf #1.JPG (79.77 KiB) 6499 mal betrachtet

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Schlupf Problematik

Beitrag von hamlet » 12 Jun 2020, 12:55

Hallo Joachim,
Schön, dass Du die Library ausprobierst!

Deine "ME"/"ICH" Anmerkung kann ich nicht nachvollziehen. Der "ME"-Eingang des "MPos" Objekts steht für "Motor End". Vielleicht hat ein Übersetzer einen Streich gespielt?

In Deinem Hauptprogramm ist die Bitmap 0b100 am "MbE"-Eingang faul. Die Bits werden von rechts gezählt. MbE wartet auf die Positionierung des Motors mit ID=2. Und da kann er lange warten, da Du den ID=2 Motor entfernt hast. Für Motor ID=0 müsste die Bitmap 0b001 lauten. Wenn Du nur auf einen Motor wartest kannst Du auch "MiE" mit ID=0 verwenden oder bei mehreren Motoren einfach die entprechenden "MiE" hintereinandersetzen.

Wie die 30 im Interface Test zustande kommt kann ich nur vermuten. Ich wusste gar nicht, dass Interface Test und Programm parallel laufen können. Das sind wahrscheinlich die akkumulierten TICs der Initialisierung, d.h. vom Anfahren des Schalters und des langsamen Zurückfahrens bis der Schalter wieder öffnet.

Grüße,
Helmut

jomifa
Beiträge: 41
Registriert: 09 Jun 2019, 15:22

Re: Schlupf Problematik

Beitrag von jomifa » 12 Jun 2020, 15:42

Hallo Helmut,
kurze Zwischenmeldung. Nach einigen Tests mit deinem Programm konnte ich feststellen, das bei der Einnahme verschiedener Positionen das Programm fehlerfrei immer auf den Ausgangspunkt zurück fand. Jetzt muss ich nur noch schauen, wie dein Programm an die Anforderungen meines Programms eingebunden werden kann. Ich muss das Erreichen einer NotAus Situation in deinen Ablauf mit einbauen. Ich habe in dem jetzigen Programm vorgesehen, dass sobald eine NotAus Situation für eine Achse vorliegt, das gesamte Programm beendet wird.

Ich danke dir noch einmal für deine freundlichen Hilfestellungen. Das gilt natürlich für alle Beteiligten, die hier mit Rat und Tat mitgewirkt haben.

Gruß,
Joachim

hamlet
Beiträge: 332
Registriert: 12 Jan 2011, 21:41

Re: Spiel Problematik bei Rast-Schnecken

Beitrag von hamlet » 13 Jun 2020, 11:19

Hallo Joachim,
Freut mich zu hören, dass die Library bei Dir funktioniert. Vielen Dank für die Rückmeldung.
Ein "NotAus" ist natürlich ein wichtiges Feature. Das hat mir keine Ruhe gelassen und ich hab da mal was vorbereitet … EncdrMotPos_EStop.rpp
Ein simpler globaler Brute Force Ansatz. Ich hab es noch nicht testen können, sollte/könnte/müsste (-; aber funktionieren.
Grüße,
Helmut

Code: Alles auswählen

Emergency Stop.
Calling the MEstp function should immediately stop all all motors handled by MPos position controllers.
You have to place one instance of MEstpProc in your main programm.
Place the MEstp functions wherever you detect an emmergency situation.

Implementation:
By running through the MEstp function the global variable M_Estp is set. This starts the process in MEstpProc.
The MEstpProc process assigns in an endless loop repeatedly a zero speed request to all motors. These requests are tunneled
via the global variable M_Off into the MPos objects, where they are directly forwarded to the ROBOPro motor output.

Antworten