Jump to content

Recommended Posts

Geschrieben

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

Geschrieben

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 ?

Geschrieben
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.

Geschrieben

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

 

Geschrieben

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?

Geschrieben

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.

Geschrieben

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

  • 2 weeks later...
Geschrieben

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

Geschrieben

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! ;D

Geschrieben

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.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...