arminiusdc Geschrieben July 6, 2012 at 14:06 Geschrieben July 6, 2012 at 14:06 hi, habe den Stepper und spiele gerade damit rum Stepper 1.0 FW 1.1.6 brickd 1.0.8 IO-4 1.0 FW 1.1.0 initiallisiert ist der Stepper mit my $step = stepper->new( $host, $port, '9ekEFBE4X9N', { debug => 1, set_max_velocity => 500, set_speed_ramping => [4000,4000], set_step_mode => 8, set_motor_current => 100, set_current_position => 0, set_minimum_voltage => 5000, CALLBACK_POSITION_REACHED => sub(){ shift }, }); ich fahre den Stepper mit $io->set_interrupt($pin); $io->CALLBACK_INTERRUPT(sub(){ if( $_[1] & $pin) { $step->stop ; $flag = 1; } }); $step->enable; $step->drive_backward; while( !$flag ) { $io->wait(0); } $io->set_interrupt(0); $step->stop; $step->set_current_position(0); $step->disable; bereite den IO-4 vor dann fahre ich rückwärts mit stepper -> drive_backward und warte bis der IO-4 auslöst. danach stepper -> stop dann stepper -> set_current_position(0); dabei ist mir aufgefallen: 1.) Wenn ich stepper -> stop ohne Bewegung rufe (weil ich schon in Null position bin) bewegt sich der Stepper noch einmal. 2.) Wenn ich danach den Stepper mit Stepper -> set_target_position bewegen will ist er bockig und bewegt sich kein Stück mehr ich muss ein Stepper -> full_brake machen damit er auf die set_target_position reagiert. 3.) CALLBACK_NEW_STATE ist nervig und sollte bitte abschaltbar sein. mfg Armin Zitieren
Nic Geschrieben July 6, 2012 at 14:20 Geschrieben July 6, 2012 at 14:20 Erstmal nur zu 3) allgemein muss man einen Callback nicht registrieren, dann nerven die auch nicht Zumindest gilt das für die C# Bindings und in meiner Delphi-Implementation. Ich vermute, beim o.g. handelt es sich um Perl-Bindings. Sind die wasserdicht getestet ? Zitieren
arminiusdc Geschrieben July 6, 2012 at 20:46 Autor Geschrieben July 6, 2012 at 20:46 es geht darum, daß die Socket sinnlose Packete empfängt bzw brickd welche schickt. Und somit Trafik erzeugt was Zeit und Bandbreite kostet. Die Perl-Bindings sind von mir und gut getestet. mfg Armin Zitieren
borg Geschrieben July 6, 2012 at 21:44 Geschrieben July 6, 2012 at 21:44 1.) Wenn ich stepper -> stop ohne Bewegung rufe (weil ich schon in Null position bin) bewegt sich der Stepper noch einmal. 2.) Wenn ich danach den Stepper mit Stepper -> set_target_position bewegen will ist er bockig und bewegt sich kein Stück mehr ich muss ein Stepper -> full_brake machen damit er auf die set_target_position reagiert. Kann ich beides nicht reproduzieren. Wenn du im Brick Viewer auf "Stop" klickst wenn er im 0 Punkt ist, bewegt sich der Schrittmotor dann auch? Falls nein, guck doch mal wo der Unterschied liegt in den Daten die übertragen werden (am einfachsten vermutlich mit Wireshark). 3.) CALLBACK_NEW_STATE ist nervig und sollte bitte abschaltbar sein. Mh, jo. Baue ich mal ein enable/disable für ein beim nächsten Update. Hab ich nicht so drüber nachgedacht, bei den ganzen anderen Callbacks gibt es ja eine Periode die man auf 0 stellen kann zum ausstellen. Zitieren
arminiusdc Geschrieben July 7, 2012 at 15:04 Autor Geschrieben July 7, 2012 at 15:04 Also kann ich auch mit brickv nachvollziehen. 1. enable 2. forward 3. disable dann bleibt der Motor stehen aber die Position zählt weiter und das Tempo bleibt. 4. enable Position bleibt stehen Tempo ist noch da. nimmt keine set_pos befehle an. 5. stop Motor bewegt sich weiter wahrscheinlich weil er das Tempo abbauen will. Kann mann auch ohne Motor nur mit stepper-brick nachvollziehen. Wäre schön wenn disable auch alles andere anhält. Zum Anfahren der 0-Position fahre ich den Stepper rückwärts gegen den Endschalter dann sollte er schnell stoppen mit stop tut er das erstmal nicht. Mit ramp 0,0 schon ein bisschen besser. Aber von der Logik her dachte ich einfach disable und fertig. Armin Zitieren
borg Geschrieben July 7, 2012 at 20:10 Geschrieben July 7, 2012 at 20:10 Ah, jetzt verstehe ich dein Problem. Enable/Disable und Start/Stop sind einfach etwas anderes. Wenn du Disable aufrufst, wird quasi einfach die Verbindung zum Schrittmotor gekappt und er kann "Auslaufen". Wenn aber z.B. FullBrake aufgerufen wird, wird aktiv gebremst je nach Kraft des Motors und Drehzahl kann das richtig brutal sein. Bei Stop wird natürlich die eingestellte Debeschleunigung genutzt. Daher finde ich das verhalten bis dahin richtig: Du trennst die Verbindung zum Motor aber der Rest läuft intern weiter. Stoppen kannst du ja immernoch mit Stop oder auch mit FullBrake (nach dem Disable, danach ists ja nicht mehr "brutal"). Soweit so gut bis dahin. Wenn du jetzt aber her gehst und wieder Enable machst und der Motor läuft intern noch, dann kann ich die noch anliegende Geschwindigkeit eigentlich nicht auf den Motor geben, der kann mit dieser im Zweifelsfall nicht anfahren und vielleicht ist es nicht gewollt, also lasse ich es. Das ist jetzt sehr unschön war mir aber bekannt bis dahin. Richtig buggy wird es allerdings wenn du jetzt Stop aufrufst. Weil dann fängt der Motor doch mit der hohen Geschwindigkeit an zu drehen und beschleunigt von da aus runter. An der Stelle ist einfach die Stepper Brick interne State Machine kaputt. Jetzt stellt sich mir natürlich die Frage was hier das korrekte vorgehen ist. Ich tendiere gerade dazu einfach bei einem Aufruf von Disable intern ganz normal das Disable durchzuführen wie es jetzt ist und danach noch ein FullBrake aufzurufen. Dadurch wird intern die State Machine in einen vernünftigen Zustand gebracht. Natürlich ist die eingestellte Geschwindigkeit dann weg und Schritte hab ich mit hoher Wahrscheinlichkeit auch verloren (Schrittmotor läuft aus)! Meinungen dazu? Zitieren
AuronX Geschrieben July 8, 2012 at 00:36 Geschrieben July 8, 2012 at 00:36 Ich denke den internen Zustand auf null zu stellen ist das einzig sinnvolle. Du kannst keine guten Annahmen über die reale Geschwindigkeit treffen, also ist es am Besten anzunehmen, dass der Motor danach steht (auch wenn das durch Leerlauf-Rollen falsch sein könnte). Null ist zumindest die wahrscheinlichste Annahme UND am wenigsten fehleranfällig. Zitieren
arminiusdc Geschrieben July 8, 2012 at 07:52 Autor Geschrieben July 8, 2012 at 07:52 hallo, ich denke auch wenn disable dann hält der Stepper irgentwie an also muß auch der interne Status angehalten werden. Das macht er auch dann bei enable mit den Schritten aber nicht mit der Geschwindigkeit. Also ich bin auch für disable wenn vorher enable, sollte alles zurücksetzen ( full_brake ). Armin Zitieren
borg Geschrieben July 8, 2012 at 10:02 Geschrieben July 8, 2012 at 10:02 Alles klar, machen wir das so. In der Zwischenzeit einfach nach dem Disable ein FullBrake aufrufen, hat dann den gleichen Effekt. Danke für das Feedback . Zitieren
arminiusdc Geschrieben July 21, 2012 at 17:34 Autor Geschrieben July 21, 2012 at 17:34 Hallo Leute, noch ne komische Sache: wenn ich drive_forward set_max_velocity(0) mache bewegt der Stepper sich trotzdem mit 1/Zeiteinheit . ist das so gedacht ?? mfg Armin Zitieren
arminiusdc Geschrieben July 21, 2012 at 17:39 Autor Geschrieben July 21, 2012 at 17:39 noch eine Anmerkung Der Stepper ist schneller als wenn ich set_max_velocity(1) einstelle. d.h. velocity = 1 macht was man erwartet velocity=0 ist total komisch. Ausprobiert auch mit dem brickv. mfg Armin Zitieren
Nic Geschrieben July 23, 2012 at 09:18 Geschrieben July 23, 2012 at 09:18 Ist mir auch schon aufgefallen. Wenn MaxVelocity=0 sollte sich der Stepper weder vor- noch rückwärts bewegen dürfen. Zitieren
borg Geschrieben July 23, 2012 at 09:33 Geschrieben July 23, 2012 at 09:33 Kümmer ich mich drum . Zitieren
borg Geschrieben July 24, 2012 at 15:47 Geschrieben July 24, 2012 at 15:47 Neue Stepper Brick Firmware ist da: http://download.tinkerforge.com/firmwares/bricks/stepper/ Zitieren
arminiusdc Geschrieben July 24, 2012 at 16:21 Autor Geschrieben July 24, 2012 at 16:21 Hallo borg, schön das die neue Firmware da ist. Das Problem mit der set_max_velocity(0) ist immer noch da. mfg Armin p.s. die Schnittstelle schau ich mit jetzt an. Zitieren
arminiusdc Geschrieben July 24, 2012 at 16:32 Autor Geschrieben July 24, 2012 at 16:32 Hallo borg, du wolltest CALLBACK_NEW_STATE abschaltbar machen. Was ist daraus geworden. und velocity(0) bitte teste im Brickv enable -> forward -> max_vlocity(0) ( Regler ganz nach unten ziehen ) dann bewegt er sich lustig weiter. mfg Armin Zitieren
borg Geschrieben July 24, 2012 at 17:41 Geschrieben July 24, 2012 at 17:41 Ah, ich hab gefixt das er losdreht wenn max_velocity auf 0 gesetzt war. Dieses Problem hatte ich gar nicht auf dem Schirm. Hab dafür schnell noch eine neue Version gebacken, sollte jetzt auch gehen. Die CALLBACK_NEW_STATE Sache ist aufwändiger, da muss ich ja neue API hinzufügen, also alle Bindings neu versionieren. Mache ich wenn es das nächste mal irgendwo eine API Änderung gibt! Zitieren
arminiusdc Geschrieben July 24, 2012 at 18:05 Autor Geschrieben July 24, 2012 at 18:05 Hallo borg, noch ein Fehler. Mit der neuen MasterbrickFirmware 1.2.3 wird der Joystick callback CALLBACK_PRESSED nicht mehr ausgelöst. Wenn ich den Joystick an den Stepper 1.1.7 hänge ist alles so wie vorher also richtig ( wird ausgelöst). Und noch mal zum Stepper, einfach keine Befehle annehmen wenn die velocity 0 ist, ist auch keine Lösung ( das hat mich jetzt ca 2 h gekostet ). Also für meinen Teil haben mir die neuen Firmwares nichts gebracht. Also nächstesmal bitte besser testen oder veröfftlicht als beta, damit man weiß das die noch nicht ausreichend getestet wurden. mfg Armin p.s. Ich habe jetzt alle Fehle hier angehängt. Macht mal bitte eine Fehler Topic auf damit das gesammelt wird. Zitieren
arminiusdc Geschrieben July 24, 2012 at 18:09 Autor Geschrieben July 24, 2012 at 18:09 hallo Borg, hatte deine Antwort übersehen. Teste jetzt 1.1.8. mfg Armin Zitieren
arminiusdc Geschrieben July 24, 2012 at 18:11 Autor Geschrieben July 24, 2012 at 18:11 hallo brog, 1.1.8 macht jetzt deutlich besser. Danke. mfg Armin Zitieren
arminiusdc Geschrieben July 27, 2012 at 09:51 Autor Geschrieben July 27, 2012 at 09:51 Hallo Borg, noch was die 1.1.8 meldet sich als 1.1.7 . mfg Armin Zitieren
Nic Geschrieben July 27, 2012 at 09:58 Geschrieben July 27, 2012 at 09:58 Richtig, habe ich auch gesehen. Und wenn das TF ändern sollte, bitte auch gleich den Fehler bei der Timebase Funktion: Die Zeitdehnung (Timebase) bei Rampenfahrten NICHT zu berücksichtigen wenn Acc bzw Deacc gleich 0 sind. http://www.tinkerunity.org/forum/index.php/topic,214.msg4988.html#msg4988 Zitieren
borg Geschrieben July 29, 2012 at 20:21 Geschrieben July 29, 2012 at 20:21 Ups, ich hab die letzter Version im Downloadbereich einfach einmal dreisterweise überschrieben. Es sollte jetzt 1.1.8 angezeigt werden . Zitieren
arminiusdc Geschrieben July 30, 2012 at 12:17 Autor Geschrieben July 30, 2012 at 12:17 hallo, ok zeigt jetzt 1.1.8. Super. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.