arminiusdc Posted July 6, 2012 at 02:06 PM Posted July 6, 2012 at 02:06 PM 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 Quote
Nic Posted July 6, 2012 at 02:20 PM Posted July 6, 2012 at 02:20 PM 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 ? Quote
arminiusdc Posted July 6, 2012 at 08:46 PM Author Posted July 6, 2012 at 08:46 PM 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 Quote
borg Posted July 6, 2012 at 09:44 PM Posted July 6, 2012 at 09:44 PM 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. Quote
arminiusdc Posted July 7, 2012 at 03:04 PM Author Posted July 7, 2012 at 03:04 PM 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 Quote
borg Posted July 7, 2012 at 08:10 PM Posted July 7, 2012 at 08:10 PM 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? Quote
AuronX Posted July 8, 2012 at 12:36 AM Posted July 8, 2012 at 12:36 AM 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. Quote
arminiusdc Posted July 8, 2012 at 07:52 AM Author Posted July 8, 2012 at 07:52 AM 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 Quote
borg Posted July 8, 2012 at 10:02 AM Posted July 8, 2012 at 10:02 AM 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 . Quote
arminiusdc Posted July 21, 2012 at 05:34 PM Author Posted July 21, 2012 at 05:34 PM 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 Quote
arminiusdc Posted July 21, 2012 at 05:39 PM Author Posted July 21, 2012 at 05:39 PM 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 Quote
Nic Posted July 23, 2012 at 09:18 AM Posted July 23, 2012 at 09:18 AM Ist mir auch schon aufgefallen. Wenn MaxVelocity=0 sollte sich der Stepper weder vor- noch rückwärts bewegen dürfen. Quote
borg Posted July 24, 2012 at 03:47 PM Posted July 24, 2012 at 03:47 PM Neue Stepper Brick Firmware ist da: http://download.tinkerforge.com/firmwares/bricks/stepper/ Quote
arminiusdc Posted July 24, 2012 at 04:21 PM Author Posted July 24, 2012 at 04:21 PM 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. Quote
arminiusdc Posted July 24, 2012 at 04:32 PM Author Posted July 24, 2012 at 04:32 PM 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 Quote
borg Posted July 24, 2012 at 05:41 PM Posted July 24, 2012 at 05:41 PM 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! Quote
arminiusdc Posted July 24, 2012 at 06:05 PM Author Posted July 24, 2012 at 06:05 PM 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. Quote
arminiusdc Posted July 24, 2012 at 06:09 PM Author Posted July 24, 2012 at 06:09 PM hallo Borg, hatte deine Antwort übersehen. Teste jetzt 1.1.8. mfg Armin Quote
arminiusdc Posted July 24, 2012 at 06:11 PM Author Posted July 24, 2012 at 06:11 PM hallo brog, 1.1.8 macht jetzt deutlich besser. Danke. mfg Armin Quote
arminiusdc Posted July 27, 2012 at 09:51 AM Author Posted July 27, 2012 at 09:51 AM Hallo Borg, noch was die 1.1.8 meldet sich als 1.1.7 . mfg Armin Quote
Nic Posted July 27, 2012 at 09:58 AM Posted July 27, 2012 at 09:58 AM 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 Quote
borg Posted July 29, 2012 at 08:21 PM Posted July 29, 2012 at 08:21 PM Ups, ich hab die letzter Version im Downloadbereich einfach einmal dreisterweise überschrieben. Es sollte jetzt 1.1.8 angezeigt werden . Quote
arminiusdc Posted July 30, 2012 at 12:17 PM Author Posted July 30, 2012 at 12:17 PM hallo, ok zeigt jetzt 1.1.8. Super. Quote
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.