borg

Mh, müssen wir uns angucken. Was haben die denn da wieder geändert, dass der Installer nicht mehr geht? Ist Mountain Lion überhaupt schon veröffentlicht?

Also bei mir gibt es keine Probleme mit meinem Thinkpad X41 mit der IMU. Kannst du das unter Debian mal mit strace starten und gucken ob irgendein sinnvoller Hinweis dabei rumkommt?

@Markus: Bin noch nicht dazu gekommen, Schaltplan gibt es bei uns in der Dokumentation unter "Resources": http://www.tinkerforge.com/doc/Hardware/Bricks/Servo_Brick.html#resources

Es gibt Changelogs im git, z.B.: https://github.com/Tinkerforge/master-brick/blob/master/software/changelog Wäre aber vermutlich nicht schlecht die auch irgendwie mit in den Downloadbereich zu packen .

Die API ist zu 100% threadsafe.

Die Hintergrundbeleuchtung vom LCD und der Distance IR Sensor werden über die 5V vom PC betrieben. Dein PC liefert weniger Spannung wenn du den Strom erhöhst (Das gilt leider auch für die USB Power Supply bei uns im Shop und für alle anderen billigen "USB Ladegeräte"). Das kannst du nur mit einer Step-Down Power Supply umgehen.

Das Log sieht soweit gut aus. Sagt er vielleicht beim starten von brickd das ihm gudev fehlt? Du brauchst python-gudev für die Hotplug Funktionalität.

Ich befürchte die C Bindings achten nicht auf Endianness und die WRT haben einen Prozessor mit MIPS Architektur (Big Endian). Die Mikrocontroller auf den Bricks erwarten Little Endian. Das steht schon seit langer Zeit auf meiner TODO Liste, sollten wir wirklich fixen.

Kannst du uns davon ein Log besorgen? In der config.py im brickd Order LOGGING_LEVEL auf logging.DEBUG setzen. Die Logfile liegt dann in /var/log/brickd Also manchmal tauchen beide Slaves auf? Oder geht es nie? Wenn der zweite Slave manchmal auftaucht klingt es doch so als sei die Baudrate zu hoch eingestellt. Kannst du zum testen mal kürzere Kabel verwenden? Um zu gucken ob die Kabellänge hier bei dem Problem überhaupt relevant ist.

So, hab das mal gerade nachgestellt (siehe Anhang). Aufbau v.l.n.r.: Master mit RS485 Extension, versorgt über USB vom PC, konfiguriert als RS485 Master mit Slaves 2 und 3, Termination On (brickv1.jpg) Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 3) und Termination Off (brickv2.jpg) Master mit RS485 Extension, versorgt über USB Power Supply, konfiguriert als RS485 Slave (Adresse 2) und Termination On (brickv3.jpg) Das funktioniert einwandfrei bei mir. Ist das jetzt so äquivalent zu deinem Aufbau? Wenn nicht, wie kann ichs nachstellen ? Edit: Was mir da noch zu einfällt: Hast du auch die Slaves vor dem Master gestartet? Es gibt da kein "Hotplug".

Der Prozessor und RAM und weiterer kram ist auf einem kleinen Zusatzboard das aufgesteckt wird: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G134032695534 Das ist 42x25mm groß und würde zwischen unsere board-to-board Stecker passen. Da kriege ich das große Leuchten in den Augen . Ist das erste Modul dass ich sehe, welches man verwenden könnte um ein "Linux-Master Brick" zu machen. Leider gibts zu dem Board keine Preise und noch nichtmal ein Pinout o.ä.

@Nic: Das glaube ich nicht. Zum einen hab ich das mit RS485 getestet und zum anderen hat er ja die Slaves beide beim Master angegeben. Ist mir nicht ganz klar was da los ist. @Salvo: Kannst du das ganze denn mit einem Teilnehmer einwandfrei nutzen oder gibt es da Timeouts o.ä.? Falls ja würde ich mal versuchen die Geschwindigkeit runterzustellen.

Welche Firmware Version haben die Master Bricks? Sind die Termination Schalter passend geschaltet?

Ah. Das ist schlecht. Eine neue Pulsweite wird erst nach ablaufen einer Periode gesetzt. Alles andere wäre für einen Servo auch nicht das richtige verhalten. Welche Auflösung braucht denn das PWM? 50Hz ließe sich ja auch mit einem IO4 Bricklet erreichen.

Wir sind da natürlich Abhängig vom Scheduling auf dem Linux Board. An und für sich sieht der USB Standard vor, dass einmal pro ms der Brick gepollt wird. Dadurch wäre eine maximale Verzögerungszeit von 1ms + 1µs (Bearbeitszeit auf dem Servo Brick) gegeben. Was der Linux Kernel jetzt aber macht wenn nicht genug Rechenpower da ist das ganze durchzuführen, kann ich nicht sagen .

Um andere RS485 Devices auszulesen? Das ist nicht vorgesehen. Wie würde das aussehen? Soll das über eine API vom PC möglich sein oder indem man Firmware verändert? Stell ich mir alles irgendwie nicht so einfach vor.

Der Modbus RTU kram ist eigentlich schon dokumentiert: http://www.tinkerforge.com/doc/Software/IPConnection_Modbus.html Dazu gibt es dann zu jedem Brick/Bricklet nochmal eine Seite mit den jeweiligen IDs etc: http://www.tinkerforge.com/doc/index.html#bricks

Im Moment gibt es das noch nicht. Wir haben schon mit dem einen oder anderen großen deutschen Elektronikversandhändler gesprochen. Die haben da zwar großes Interesse dran, allerdings erreichen wir die Margen die wir dafür bräuchten im Moment einfach noch nicht. Wir haben vor Ewigkeiten mal eine Preisliste angelegt für Reseller: http://www.tinkerforge.com/reseller_conditions Allerdings ist uns Mittlerweile bewusst, dass die Preise dort absolut uninteressant sind für Versandhändler. Wenn wir aber an jedem Brick/Bricklet nur wenige Cent verdienen sind die Händler für uns uninteressant. Wenn wir jetzt hergehen würden und die Preise für jedes Produkt um 25% erhöhen würden, würde hier vermutlich Chaos ausbrechen ! Das ist also auch keine richtige Alternative.

Auf den ersten Blick behandle ich das genau genauso wie bei RS485 (und da funktionierts). Muss ich mir dann nochmal genauer angucken .

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.