borg

Oh, Tatsache. Habs in der config gefixt: https://github.com/Tinkerforge/generators/commit/6cbee91682a19d5d1ad6f57ac42373717e936f28 Das nächste mal wenn es neuen Binding Versionen gibt ist der Fix mit drin.

Mh, hast du die neueste Master Brick Version getestet? Ich hatte anfangs den gleichen Bug bei RS485, hab dann aber herausgefunden woran es liegt und eigentlich sowohl für RS485 als auch für Chibi gefixt!

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 .

@webster7567: Was du da rausgesucht hast ist definitiv geeignet. Eine Anleitung zum einrichten des Raspberry PI haben wir auch: http://www.tinkerforge.com/doc/Embedded/Raspberry_Pi.html Aber das hat sich ja dann jetzt vermutlich schon erledigt, schade .

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?

Mh, also das hier: Sieht so aus als würdest du versuchen 2 brickd gleichzeitig zu starten? Kannst du mal gucken ob da zwei laufen (ps aux)? Und evtl alle mit einem killall killen und nochmal versuchen? Wenn das nichts bringt wäre eine Logfile interessant wo das abstecken per USB mit drin ist. Hier ist es jetzt erst ab dem brickd neustart.

Also du hast deinen Stack und er funktioniert. Dann ziehst du USB ab und brickd ist weg? Das ist ja komisch. Kannst du mal in (vermutlich) /usr/share/brickd/config.py das LOGGING_LEVEL auf logging.DEBUG setzen und gucken was nach einem Absturz in /var/log/brickd.log steht?

Genau richtig was AuronX sagt. Für deinen Fall würde man einfach von high auf low setzen, dann einen Zähler nehmen der bis 75 zählt und dann wieder von low auf high (oder andersrum). Wie gesagt, gucke ich mir an. Hab mir vorgenommen einen Tag pro Woche zu investieren um neue API zu implementieren, die TODO Liste dafür ist ein wenig angewachsen . Letzte Woche hab ich ja schon ein bisschen API hinzufügen können.

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

Ne, dafür brauchst du keinen zweiten Master Brick (würdest du bei der WIFI Extension auch nicht brauchen). Grundsätzlich ist es ja so, dass eine TCP/IP Verbindung zwischen dem Brick Daemon und dem Programm was du schreibst aufgebaut wird. Ob diese Verbindung nun über WLAN, über das Internet, über UMTS oder wie auch immer aufgebaut wird ist vollkommen egal. Der Master am embedded Board verhält sich sozusagen so als wäre er bei dir am PC!

Den 4. Punkt auf der Startseite sollten wir entfernen, da gebe ich dir vollkommen recht! Kameraseite: embedded Board, daran per USB angeschlossen: Bricks und Bricklets und ein WLAN-USB-Stick. Auf diesem Board läuft brickd und es verbindet sich mit einem Access Point oder direkt per Ad Hoc mit deinem Laptop. Laptop: Die IP Connection in dem Programm auf deinem Laptop verbindet sich über den AP oder Ad Hoc mit dem brickd auf dem embedded Board (die IP des Boards angeben anstatt "localhost", genauso wie es mit der WIFI Extension auch wäre). Das ist alles. Von der Programmierung her ist alles exakt genauso wie es mit der WIFI Extension auch wäre. Anstatt die WIFI Extension zu konfigurieren musst du das embedded Board konfigurieren und dort den Brick Daemon installieren. Sonst ist alles gleich!

Ah, also ein "wiederkehrender Monoflop". Sowas ist technisch auf jedenfall möglich (solange wir in der 1ms Auflösung bleiben). Einmal zur Erklärung: Auf den EEPROMs auf den Bricklets sind Plugins gespeichert die von den Bricks beim starten eines Stacks eingelesen werden. In diesen Plugins gibt es eine "tick_task" die von dem Brick einmal pro ms ausgeführt wird. Maximale Ausführungszeit ist 100us. Alles was man damit machen kann ist auch möglich. Ich habs mir mal auf die TODO Liste geschrieben, gucke ich mir an wenn ich mir die Monoflop Geschichte für die IOs angucke.

Cool .

@webster7567: Ich würde dir empfehlen ein kleines embedded Board zu nehmen und dort den Stack dranzumachen. Dadrauf kann dann der brickd laufen und du kannst von außen steuern. Die Funkverbindung zwischen dem embedded Board und dem Steuer-PC kann über irgendwas passieren was TCP/IP spricht, z.B. ein USB-WLAN-Stick. Ein Raspberry PI + ein günstiger WLAN Stick wird noch nichtmal teuerer sein als Master+Chibi. Die Übertragung muss aber natürlich nicht per WLAN passieren, such dir halt etwas raus was die Reichweite und den Durchsatz schafft den du brauchst. Was bringt es dir wenn wir Chibi wieder auflegen aber deine 2000€ Seilkamera bleibt während des Events irgendwo stecken weil die Übertragung nicht stabil genug ist? Wenn ich ein kleines RC Modell steuere ist das nicht ganz so schlimm, einmal neustarten und weiter geht es. Aber gerade auf Grund von Anwendungsfällen wie den von dir beschriebenen haben wir Chibi erstmal gestrichen!

Du redest von einem Monoflop für die drei? Oder meinst du jetzt was anderes?

Ich gucke mir das mit der Frequenz nochmal an, das ist aber an der Stelle leider wirklich nicht so einfach wie es aussieht. Die PWM und Timer Counter Hardwareeinheiten haben 16bit register, von daher gibt es dort eine Beschränkung auf 65535. Das ist an der Stelle erstmal Einheitslos, da kommt es dann jetzt drauf an auf welche Frequenzen die Clocks usw stehen. Dort könnte man evtl. noch dran drehen und die Frequenzen nach Bedarf umstellen, es ist aber keine Sache von 5 Minuten.

Das ist eine Zener Diode.

@Wumpus: Ich hatte eigentlich gehofft das die neuen Stepper Bricks heute ankommen, sind sie aber leider nicht. Ich würde also von morgen ausgehen.

Überprüf nochmal ob der Port den du eingestellt hast korrekt ist und dann nochmal mit anderem Kabel probieren (wie Wumpus schon gesagt hat).

Wir haben damals gesagt wir gucken uns Chibi nochmal an wenn WIFI draußen ist und dazu stehen wir auch . Zumindest mit unveränderter Software werden wir die Chibi Extensions nicht nochmal verkaufen, dazu gab es einfach zuviele Probleme. Ob eine neue Hardware notwendig ist oder nicht wird sich zeigen.

müsste ich mir angucken. Bei der IO4 geht das bestimmt, für die IO16 bräuchte ich vermutlich mehr counter als ich platz auf dem Plugin hab .

@Ts2004: Ich würde nicht ausschließen das wir ein RS232 Bricklet auf Dauer haben, wird allerdings noch ein bisschen dauern.

Mh, ist das Rotary Poti Bricklet vielleicht nicht geflasht? Dazu einfach mal den Master alleine nehmen, anmachen und dann das Rotary Poti Bricklet dranmachen und über den Brick Viewer flashen. Edit: Wenn es gar nicht geflasht ist fehlt vermutlich auch die UID, die solltest du dann auch ein setzen.

In der neuesten Stepper Brick Firmware gibt es jetzt die Möglichkeit eine Zeitbasis zu setzen (1s - 2^32s). Damit ist es jetzt möglich bis runter auf 1 Schritt pro 136,2 Jahre zu gehen. Ich hoffe das ist jetzt langsam genug .

GetAllData und state Callbacks gibt es jetzt in der neuesten Stepper Brick Firmware .