arminiusdc

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

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

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

Hallo, habe noch mal die Schnittstellen überarbeitet. mit new kann ich auch gleich initiallisieren new( [ (host,port)|IO::Socket::Inet],[GUID],[ini]) Ini ist ein Hash mit [funktion|Para] => [ value | Arrayref ] Beispiel für den Stepper 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 }, }); Fehler werden nur noch mit dem Para debug true ausgegeben. so wait kann auch vom obj gerufen werden also $step->wait(0); wartet hier bis CALLBACK_POSITION_REACHED eingetreten ist. Außerdem können die Callbacks was returnieren. Mit dem Parameter wait werden nicht verarbeitet CALLBACK´s auf dem STDERR gemeldet. mfg Armin brick.pm stepper.pl brick_rumpf.pm brick_gen.pl

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

Hi, ich habe noch schnell den einen Generator gebastelt der die Bindings/*.py in brick.pm umschreibt. In Perl weil *.py kann ich nicht. Vorraussetzung ist im gleichen Verzeichnis sind die Bindings/*.py und brick_rumpf.pm. Dann einfach brick_gen.pl starten und er baut brick.pm. Habe gesehen ihr baut ständig an den Schnittstellen rum deswegen doch der Generator. Dazu noch eine Frage was ist der Unterschied zwischen CHAR und STRING ? und wann gibt es wieder Stepper-Bricks ? Anbei noch die neueste brick.pm. mfg Armin brick_gen.pl brick_rumpf.pm brick.pm

Hi so Urlaub ist zu Ende habe die Schnittestelle jetzt angepasst. Man kann new nun auf 3 Arten ansprechen Class->new( host, port, uid ) Class->new( IO::Socket::INET, uid ) obj->new( Class, uid ) damit können jetzt alle Objekte die gleiche Socket benutzen. Anbei wieder ein t1.pl was alle 3 Arten benutzt. Die Doku kommt später. mfg Armin brick.pm t1.pl

Also zu 2) ich habe in Perl noch nicht mit Threads gearbeitet deswegen ohne. Die Callbacks werden nicht gepollt, sondern mit IO::Select wird auf eine Antwort vom brickd gewartet. Die Schnittstelle brick::wait gestattet, daß nur auf bestimmte Brick(let)s gewartet wird. zu 1) Deshalb hat auch jeder Brick(let) seine eigene Socket. Außerdem kann man mit meinem Konzept, Brick(let)s von verschieden Rechner ansprechen. Wenn ihr nun das brickd-Konzept ändert, muß ich natürlich meine Schnittstellen anpassen. Aber diese Änderung wäre eine deutliche Einschränkung der Funktionalität. Dann könnte ich nicht mehr mehrere Programme auf einem Rechner paralell starten und ein Programm könnte nicht Brick(let)s von verschiednen Rechner kontrollieren. Das jetzige Konzept ist optimal geeignet, für die Lehre, zur Übung von IPC und verteiltem Rechen. Ich hoffe also das ihr das alte Konzept beibehaltet. mfg Armin

habe eine brick.pm gebastelt um den Spass auf in Perl zu benutzen. Braucht Math::Int64. Alle Funtionen der Bricks und Bricklets sind aus der TCP - Doku entnommen. Die Callbacks werden mit der Funktion brick::wait(timeout,brick1, .. , brickn) verarbeitet. Jeder Brick(let) hat seine eigene Socket zum brickd. Doku fehlt noch kommt später. Würde mich über feedback freuen. Habe zum testen eine Stepper, Servo, Master, LCD20x4, Poti, IO4, light und distance Brick(let). Habe meine Test-Programm t.pl auch drangehängt. Viel Spass beim basteln. Armin brick.pm t.pl