borg

Die IO4 ist dafür leider nicht geeignet, der Sensor zieht zuviel Strom. Desweiteren wäre die Auflösung nicht so pralle. Der Puls dauert maximal 18ms wenn ich das richtig sehe, d.h. es wäre nur eine Auflösung von 18 Schritten möglich.

Das Thema haben wir hier schon: http://www.tinkerunity.org/forum/index.php/topic,736.0.html Es funktioniert wenn du dir das .dmg z.B. mit wget ziehst (nicht mit dem Browser). OS X scheint das irgendwie als nicht-auszuführen zu kennzeichnen, vermutlich weil es nicht aus dem Apple Store kommt... Für Sachdienliche hinweise wie man das am geschicktesten umgeht sind wir natürlich dankbar .

Also ich denke das nichts vom WIFI Code ausgeführt wird, solange keine Extension mit Extension ID 3 auf einem Master sitzt: https://github.com/Tinkerforge/master-brick/commit/14047de5ff336550dbb607a43407bf20daab4bfa Die größte Änderung ist das hier (in der bricklib): https://github.com/Tinkerforge/bricklib/commit/5a106ec891fee1713ab44ed9a8d36be463010de7 Ich hab für das Auslesen aus dem EEPROM und schreiben ins Flash von den Bricklet Plugins die Buffer Größe vergrößert und locks umgesetzt, damit das schneller geht. Zusätzlich hab ich beim Master das blinken am Anfang um 1 erhöht und die Timeouts bei RS485 dynamisch an die Baudrate angepasst. Mit diesen Änderungen konnte ich bei keiner Baudrate mehr Probleme erzeugen (vorher konnte ich Probleme bei niedrigen Baudraten reproduzieren). Am Wochenende lasse ich mal ein RS485 Aufbau mit den ganzen Sensoren die salvo nutzt durchlaufen, mal schauen ob ich das dann reproduzieren kann.

Die längere Enumeration ist erwartet, an der Stelle hab ich die Timeouts hochgesetzt (d.h. ich warte bei niedriger RS485 Frequenz länger auf eine Antwort von den Slaves). Desweiteren wird am Anfang einmal mehr geblinkt. An der LED würde ich, wenn die gleiche Frequenz verwendet wird, keine Unterschiede erwarten. Die größere Firmware kommt zustande weil in 1.2.3 schon ein Großteil der WIFI Extension Unterstützung mit drin ist . Ich stelle am Wochenende mal genau deinen Aufbau nach (mit den Bricklets). Mal schauen ob es bei mir durchrennt.

Hmpf. Kann ich absolut nicht reproduzieren hier. Der eigentliche Pakettransfer ist nicht anders gestaltet, ich hab habe nur bei niedrigeren Frequenzen ein paar Timeouts erhöht. Wir haben schon einige RS485 Extensions verkauft und nur sehr wenig Problemschilderungen (eigentlich nur nur dieser Thread hier und der von wurststulle). Daher gehe ich davon aus, dass es ein Problem ist, welches nur in einer bestimmten Konstellation auftritt. Welche Bricks/Bricklets hast du eigentlich an den Stacks? Mir ist nicht klar was da stecken bleiben soll, ich werde mal einen Langzeittest mit sehr langem Kabel ausprobieren!

Mh, verstehe ich nicht. Wir blocken ja an der Stelle mit einer Semaphore und sobald wir blocken sollte die JVM schedulen. Oder nicht?

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!

Firmwares: Stepper Brick 1.1.8 Stop completely if max velocity is set to 0 while in drive mode Download Firmwares: Stepper Brick

Firmwares: Stepper Brick 1.1.8 Stoppe komplett falls max velocity auf 0 gesetzt wird im drive mode Download Firmwares: Stepper Brick

@salvo: Es gibt eine neue Firmware für den Master Brick, es gab in der Tat noch einen Bug bei niedrigen Baudraten! Ich gehe davon aus, dass die neu Firmware bei dir auch laufen wird : http://download.tinkerforge.com/firmwares/bricks/master/

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

Neue Master Brick Firmware ist online: http://download.tinkerforge.com/firmwares/bricks/master/

Firmwares: Master Brick 1.2.3, Stepper Brick 1.1.7 Stepper Brick: Stop state machine after disable call, don't drive if max velocity = 0 Master Brick: Use dynamically calculated timeouts for RS485, improve bricklet readout Download Firmwares: Master Brick, Stepper Brick

Firmwares: Master Brick 1.2.3, Stepper Brick 1.1.7 Stepper Brick: Stoppe Statemachine nach Disable Aufruf, nicht fahren falls max velocity=0 Master Brick: Dynamisch kalkulierte Timeouts für RS485, schnelleres Bricklet auslesen Download Firmwares: Master Brick, Stepper Brick

Kurzer Zwischenbericht: Da ist wirklich irgendwas faul. Ich hatte mit den unterschiedlichsten Baudraten getestet und sie hatten alle funktioniert. Aber gerade 9600 und 19200 gehen bei mir auch nicht, komisch. Edit: Ich hab das Problem gefunden. Ich hab ein Paar Timeouts zu niedrig gewählt, die musste ich dynamisch an die Baudrate anpassen. Ich gehe davon aus das ich damals erst mit hohen Timeouts getestet hab und die dann später nochmal verringert hab. Uuuuups! Ich veröffentliche heute Abend eine neue Master Brick Firmware.

Das ist ein ganz normaler 900Mhz SMA Stecker (nicht RP-SMA!).

Sollte definitiv gehen. Hast du auch beide umgestellt? Ich hab damals einige Baudrate getestet, ob 9600 und 19200 dabei waren kann ich jetzt nicht sagen, teste ich heute Abend nochmal schnell.

Ging es dir jetzt nur um das "Under Construction" im Wiki? Das könnten wir ja im Zweifelsfall einfach entfernen. Oder was könnten wir sonst tun um dem ganzen mehr "leben" zu verschaffen?

Die RS485 Extension shiftet Pinne im Stack um, es ist (im Moment) nicht möglich eine Extension anzusprechen die im Stack über einer anderen Extension sitzt. Das mache ich zusammen mit der WLAN Extension fertig.

Kümmer ich mich drum .

Die 0 und 1 sind schon dafür vorgesehen. Einstens Vorschlag wird zu nichts führen, die Pinne für die Extensions 2*(SPI+I2C+1xSelect+3xGPIO) werden im Stack geshiftet auf andere Pinne, damit die 2 Extensions elektrisch an andere Pinne am Master verbunden sind. Die Pinne mit denen die Extensions angesprochen werden sind allerdings im Moment fest. D.h. eine Extension die an "zweiter Stelle" sitzt kann im Moment definitiv nicht angesprochen werden. Wir werden auf Dauer alle Extensions, soweit technisch möglich, miteinander kompatibel machen. Die RS485 Extensions wird z.B. direkt über eine USART Schnittstelle angesprochen von der nur eine im Stack liegt. Es ist also technisch nicht möglich diese zu einer anderen Extension kompatibel zu machen die diese Schnittstelle benötigt. Da sind dann einfach irgendwo die Grenzen, wir legen ja schon 80 Pinne durch den Stack!

Ich hatte vor mich darum zusammen mit der WIFI Extension zu kümmern. Das ist viel Arbeit, da muss auch noch zusätzliche API her. Wenn du einen Stack hast der nicht per USB angeschlossen ist und der zwei Extensions hat ist ja erstmal vollkommen unklar welche dieser Extensions Master und welche Slave sein soll oder ob sogar beide Master sein sollen (wie in deinem Fall).

Mh, der Treiber IC auf dem DC Brick ist für 28V, 5A kontinuierlichen Betrieb ausgelegt. Da muss dann in deinem Fall wohl die Kühlleistung von dem kleinen Kühlkörper nicht ausreichen. Ich befürchte da muss eine aktive Kühlung her. Oder zieht der Motor vielleicht erheblich mehr Strom als offiziell angegeben? Ein "short circuit" detektiert der Treiber ab 6,5A.

Zwei Extensions gleichzeitig werden im Moment in der Firmware leider noch nicht unterstützt.

Jop, definitiv. Wir hatten keine Big Endian Maschine zur Hand und das entsprechend nicht getestet. Ich denke wir werden das auf einem MIPS Board o.ä. testen müssen. Wenn du es zum laufen kriegst würden wir uns natürlich über einen Patch freuen!