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

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 ?

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

 

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.

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

 

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?

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.

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

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 .

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

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

Ist mir auch schon aufgefallen.

Wenn MaxVelocity=0 sollte sich der Stepper weder vor- noch rückwärts bewegen dürfen.

Kümmer ich mich drum .

Neue Stepper Brick Firmware ist da: http://download.tinkerforge.com/firmwares/bricks/stepper/ 

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.

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

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!

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.

hallo Borg,

 

hatte deine Antwort übersehen. Teste jetzt 1.1.8.

 

mfg

 

Armin

hallo brog,

 

1.1.8 macht jetzt deutlich besser. Danke.

 

mfg

 

Armin

Hallo Borg,

 

noch was die 1.1.8 meldet sich als 1.1.7 .

 

 

mfg

 

Armin

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

 

Ups, ich hab die letzter Version im Downloadbereich einfach einmal dreisterweise überschrieben. Es sollte jetzt 1.1.8 angezeigt werden .

hallo,

 

ok zeigt jetzt 1.1.8. Super.