Verhalten Encoder-Motoren

[Kilian]

Hallo,

ich habe hier zwei Encoder-Motoren (3-poliges Encoderkabel) aus dem Robo-TX-Training-Lab am TX-Controller in Betrieb genommen. Das Verhalten mit Robopro entspricht nicht meiner Erwartung. Vermutlich werdet Ihr das kennen und könnt mir sagen, was ich falsch mache:

Ich habe zum Testen ein sehr simples Robopro-Programm, dass nur aus zwei Elemnten als Endlosschleife besteht:
- Encodermotor-Element (M1 Rechtslauf, Geschwindigkeit 8, Abstand Distanz 3)
- Wartezeit 0.5s.

Was nun - entsprechend meiner Erwartung - passiert ist folgendes (Motorlauf ist s, Stillstand ist _):
s______________s______________s______________s______________s______________s______________

Soweit so gut. Nun ändere ich auf Distanz 40 (Warteelement unverändert 0,5s!). Meine Erwartung:
ssssssssssssssss______________ssssssssssssssss______________ssssssssssssssss______________ssssssssssssssss______________

Tatsächlich:
ssssssssssssssss__ssssssssssssssss__ssssssssssssssss__ssssssssssssssss__ssssssssssssssss__
Wieso ist die Pause jetzt viel kürzer? Wirkt so, als würde das Warteelement schon starten, solange der Motor noch läuft?

Und dann bei Distanz 70 (Wartezeit immer noch 0,5s) passiert dies:
ssssssssssssssssssss__ssssssssssssssssssss__ss___________ssssssssss__ss__sssssssssss__sssssssssssssssssssssssssssssssssssssssssss_
Keinerlei Rhythmus mehr erkennbar.

Wenn ich beide Motoren auf Synchron-Distanz 70 stelle, scheint es fast zu funktionieren. Beide synchron etwa:
M1: ssssssssssssssss______________ssssssssssssssss______________ssssssssssssssss______________
M2: ssssssssssssssss______________ssssssssssssssss______________ssssssssssssssss______________
(Also auch mit plausibler Pausenlänge dazwischen)

Aber zwischendrin passiert auch mal sowas:
M1: ssssssssssssssss_s_s__________ssssssssssssssss______________ssssssssssssssss______________
M2: ssssssssssssssss______________ssssssssssssssss______________ssssssssssssssss_s_s_s_s______

Ich bin jetzt gerade etwas irritiert, weil mir unklar ist, wie man so exakt irgendwelche Positionen anfahren soll. Was mache ich falsch?

[fishfriend]

Hallo...
Bei DIstanz wartet das Element nicht bis es fertig ist, sondern geht zum nächsten Element.
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Bjoern]

Hallo Kilian,

du musst das Encode Signal mit auswerten. Denn nur so weißt du ja, das sich der Motor noch bewegt.
Wie Holger schon schrieb sagst du de Motor er soll eine Distanz fahren. Das macht er autark und RoboPro geht zum nächsten Befehl. Das ist deine Wartezeit. Die längere Distanz sorgt dann natürlich dafür, das deine Pause in dem Fall kleiner ist.

Die Programmausführung muss also so lange pausieren, bis die Distanz erreicht ist. Dann kommt deine Wartezeit von 0,5s.

Björn

[Kilian]

Ah, ok, verstehe. Also nach dem Motorbefehl erst noch eine Zählschleife auf C1 und danach erst die Wartezeit? Probiere ich mal aus...

[fishfriend]

Hallo...
Schau dir am besten die Hilfe an.
Unter 11.6.1 siehst du das es einen virtuellen EIngang M1E gibt.
Den fragt man ab ob das Ziel erreicht ist.
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Kilian]

Hallo,

die Hilfe (und die Bauanleitung und das Begleitheft) hatte ich durchaus schon durchforstet. In meiner Online-Hilfe von Robopro gibt es keinen Punkt 11.6.1. Der ganze Bereich 11 behandelt Kamerafunktionen und geht nur bis Unterpunkt 11.3.

Allerdings finde ich bei der Suche nach "M1E" etwas unter Punkt "4.4.2 Motorsteuerung mit Encodermotoren". Das dortige Beispiel habe ich 1:1 nachgebaut. Also M2 mit D=75 starten, dann M2E abfragen, dann M2 Stop. Danach Wartezeit 0,3s und wieder von vorn. Mein Problem mit der Wartezeit habe ich damit gelöst.

Aber richtig funktionieren will es dennoch nicht.

Erwartung wäre ja nun jeweils genau eine Umdrehung, kurze Pause, eine Umdrehung, kurze Pause usw.:
ssssssssssssssss____ssssssssssssssss____ssssssssssssssss____ssssssssssssssss____

Ich bekomme aber dennoch solche Fehler:
ssssssssssssssss____ssssssssssssssss____ssssssssss_______ssss____ssssssssssssss_s_s____ssssssssssssssss____
(Wobei er am Ende interessanterweise immer wieder auf eine volle Umdrehung kommt. Der besseren Übersichtlichkeit halber habe ich mal jeweils einen Umdrehungs_Pause-Zyklus farbig markiert)

Die Häufigkeit dieser Fehler unterscheidet sich nach Drehrichtung und Motor und Belastung. Der eine Motor macht in einer Drehrichtung ohne Last praktisch perfekt das Erwartete. In der anderen Drehrichtung gibt es ca. jede 5 Umdrehung einen Fehler. Bei meinem anderen Encodermotor ist die Fehlerhäufigkeit eher 1:3 und bei beiden steigt sie, sobald ich die Achse mit dem Finger bremse/belaste.

Meine aktuelle Anforderung, sauber mit z.B. X Hz in einem Drehwinkel von Y° hin- und her zu oszillieren ist so nicht realisierbar. Ideen?

[fishfriend]

Hallo...
Ja, ich seh gerade die Nummer ist älter auf diesem Rechner. Aber M1E ist schon die Lösung.

Es ist so, Distanz wird vom Interface gemacht nicht von RoboPro.
RoboPro sagt dem Interface Motor soll X-Schritte laufen. Interface läßt Motor laufen und meldet wenn er fertig ist, das wieder an RoboPro durch den M1E der einfach gesetzt wird. RoboPro weiß nicht wo der Motor steht und läuft weiter.
Durch Abfragen ob M1E noch nicht gesetzt ist, "sperrt" man das RoboPro Programm solange.

Kannst du mal einen Screenshot von deinem Programm zeigen?
Durch die Übertragung "kann" eine kleine Verzögerung im Programm zu unruhigem Lauf führen. Es kann auch andere Gründe dafür geben.
Es ist auch ein Unterschied ob es "Online" läuft oder ohne PC.
Mit freundlichen Grüßen
fishfriend
Holger Howey

[Dirk Fox]

Hallo Kilian,

der Distanz-Befehl wird von Robo Pro zu einem nebenläufigen Thread gemacht. Wenn Du danach eine Wartezeit programmierst, musst Du zuerst auf den Abschluss des Distanz-Befehls warten.

Hier ein Beispiel, wie das aussehen kann:

Distanz-Befehl mit Encoder

Beispielprogramm Encoder mit Distanz.jpg (45.56 KiB) 2665 mal betrachtet

Beste Grüße,
Dirk

[fishfriend]

Hallo...
Ähm, für ersten Versuche würde ich es etwas einfacher gestalten.
Fang erstmal mit einem Motor an.
Dann kann man immer noch das gleiche Programm parallel ein zweites mal für M2 laufen lassen.
Dann alles in ein Programm packen.

Ich denke das Problem ist die Blockade. Man (der Roboter) soll ja noch was anderes machen.
Dazu aber erst mal einfach loslegen.

Mit freundlichen Grüßen
fishfriend
Holger Howey

[Widi]

Hallo Kilian
Ein programm aus dem knowhow
https://ftcommunity.de/knowhow/computin ... rmotposv2/

vielleicht das was Du suchst?
Widi