borg

Im Moment ist das Protokoll welches wir auf TCP/IP Ebene sprechen leider wirklich noch nicht dokumentiert. Ich plane da genauso eine Dokumentation zu erstellen wie sie schon für die anderen Sprachen existiert, dauert aber noch ein bisschen. Wir müssen unsere TODOs da einfach priorisieren, alles auf einmal geht nicht .

Mh, no idea what to do about the problen . I currently use the following version:

If you connect the Powersupply first you need to press reset after you plugged in the USB cable.

Hallo Mcbull, normalerweise sollte es nicht länger als 2 Tage dauern bis deine Bestellung raus ist, ausnahmen gibt es Momentan bei Bestellungen mit Humidity, LCD 20x4 und IMU (ausverkauft, wir warten noch auf Bauteile für die Produktion) sowie bei Joystick (siehe letzter Blog Eintrag). Ansonsten, wenn du per Vorkasse bezahlt hast dauert es leider bis zu 5 Werktage wenn du von einer nicht-Sparkasse aus überweist bis wir das Geld haben. Das dauert dann entsprechend bis zu 7 Tage bis es raus ist .

Oh sorry. I deleted the rs485_init.c actually, but didn't committ the new CMakeList.txt .

Ooops, i actually botched that up. I somehow managed to commit some stuff from my rs485 extension branch while comitting some chibi fixes. Let me just clean up the debug code from the rs485 branch and commit the whole thing, this will take a minute. Edit: Just comittet it, the Master Brick firmware should compile now. Sorry for that!

python-gudev wird nur für hotplug benötigt. D.h. wenn brickd gestartet wird nachdem die Bricks angeschlossen wurden funktionieren diese auch ohne python-gudev. Hier hat jemand brickd auf einem Router zum laufen gebracht (NSLU): http://www.tinkerunity.org/forum/index.php?topic=52.0

Mh, ich hab um ehrlich zu sein keine Ahnung . Sieht so aus als wäre die DLL nicht richtig eingebunden oder vielleicht fehlt ihm ein Pfad zur DLL? Ich hab nur das Visual Studio Express hier zum testen, ich weiß nicht in wie weit sich das von Ultimate unterscheidet. Wenn es überhaupt nicht funktioniert könntest du versuchen einfach die Sourcen direkt zu verwenden (anstatt der DLL)?

Hast du denn die UID angepasst in dem Testprogramm?

Wenn du dir sowas wie unsere Step-Down Powersupply bastelst geht das natürlich (das ist ja quasi ein Spannungswandler).

Indeed, the "minus 1" thing is a bug. There is a +1 missing somewhere for the frequencies where the channels start at 1 instead of 0. i will fix that. Now, why only one of the frequencies work for you is really hard to say. But it is good to know that it works generally. Do you have a radio controlled thermostat near you (or something similar)? They normally use the 868Mhz band and might interfere.

What firmware versions do the Master Bricks have? And can you try another frequency? Does the Temperature Bricklet work without Chibi?

Ich hab den QT Designer noch nie unter OS X benutzt, ich wüsste aber nicht warum es dort nicht vernünftig laufen sollte. Beim Brick Daemon hatten wir in der Tat ein paar Anfangsschwierigkeiten (siehe hier: http://www.tinkerunity.org/forum/index.php/topic,213.0.html). Aber soweit ich das sehe hat seit dem die Probleme gelöst sind jeder gesagt das es stabil läuft!

Die Maximale Stack Größe ist 8. D.h. auf einen Master können 8 weitere Bricks gesteckt werden. Natürlich teilen sich alle Bricks eine USB Verbindung und der Durchsatz pro Brick wird dadurch kleiner. Bei den Bricklets gibt es keine Einschränkungen, wenn du einen Stack mit 20 Bricklet Anschlüssen hast kannst du da auch 20 Bricklets dranmachen. Auch 20 Temperature Brickelts. Da gibt es keine Probleme mit der Addressierung, wir haben bei allen I2C Bricklets die Möglichkeit die Adresse dynamisch zu verändern. Bei sehr großen Stacks sind zwei Dinge zu beachten: Es gehen ca. 1000 Nachrichten pro Sekunde über USB. Wenn 5 Master mit 20 Bricklets in einem Stack verwendet werden sind das nur noch 40 Nachrichten pro Sekunde pro Modul (Je nach Anwendung kann das vollkommen egal sein oder auch ein großes Problem sein) Ein USB Port von einem PC liefert maximal 500mA (ein embedded Board wie das Raspberry PI oder ein günstiges Netbook liefert vermutlich weniger). D.h. je nachdem wieviel Strom der Stack in Summe zieht und wieviel Strom der USB Port liefert muss eine Step-Down Powersupply her. Zwei Dual Relays können schon genug Strom ziehen um einen billigen USB Hub in die Knie zu zwingen. Da wird dann einfach eine zusätzliche Stromversorgung benötigt. Das ganze ist leider ein bisschen schwammig weil jeder USB Port/USB Hub sich anders verhält, aber da können wir leider nichts gegen machen.

I see. If that is the case everything should be alright now. As someone that doesn't use OS X normally it is quite hard to find good documentation about this low level stuff and how to use it. Also, the whole thing did work on 1.6.x!

Der Brick Viewer ist mit PyQt geschrieben (also die Python Bindings für Qt) und die GUI selbst ist mit QT-Designer zusammengeklickt: http://qt-project.org/doc/qt-4.8/designer-manual.html Das ist nicht unkomfortabler als Visual Studio (der GUI bauen Teil). Komfortabler wird Visual Studio beim debuggen, da würde ich dann empfehlen auf eine Python IDE zurück zugreifen anstatt einfach einen Texteditor + Console zu nehmen. Da gibt es aber auch viele gute.

Das würde nicht auf eine 4x4cm Platine passen. Wäre natürlich dann auch teurer. Da wird es Probleme geben! Mit einem sich verändernden Strom (Servo hat Last oder nicht) ändert sich dann auch die Spannung. Desweiteren bräuchtest du bei den Strömen die Servos ziehen vermutlich einen teuren Leistungswiderstand.

Hallo Nic, sehe ich genau andersrum. Es ist viel einfacher einen ganz einfachen Texteditor (gedit o.ä.) zu verwenden und in der Console "python mein_erstes_programm.py" aufzurufen als Visual Studio zu verwenden. Ich hab als Anfänger die ersten 2 Kapitel des Python-Einsteiger Tutorials durchgearbeitet bevor Visual Studio überhaupt installiert ist und dann weiß ich immernoch noch nicht wofür die 250 Button sind die ich anklicken kann wenn ich es das erste mal öffne .

Alright! New version is online: I managed to reproduce the problem but i did not manage to understand it unfortunately. For now i just removed the unix double fork magic completely, so the process is not running as a "real daemon". But it does work now. http://download.tinkerforge.com/tools/brickd/macos/ Sorry for the problems.

Ah, verstehe das Problem. Ich könnte ohne Probleme einbauen das er "position reached" auch aufruft wenn ein Stop Zustand erreicht wird. Würde natürlich die Semantik der API ein wenig ändern, aber ich denke das sollte eigentlich kein Problem sein hier.

OK, verstehe.

Dafür gibt es eigentlich den position_reached callback.

Also im Prinzip möchtest du eine Funktion haben die den Stepper wieder anschmeißt mit den noch ausstehenden Schritten? Sowas wie drive_remaining_steps() und dazu würde man dann vermutlich auch noch ein set_remaining_steps() machen, was das gleiche tut wie set_steps, aber den Motor noch nicht losfahren lässt. Ist das so gemeint? Schreibe ich mir auch mal auf die TODO Liste, hab ja jetzt schon mehrere Erweiterungen für den Stepper, da wäre das eine Kleinigkeit vermutlich.

Wir empfehlen für gewöhnlich Python als erste Programmiersprache. Unter Linux ist Python auch sehr gut integriert, aber im Grunde kannst du dir einfach mal die Eigenschaften der unterschiedlichen Sprachen durchlesen und selber entscheiden.

Ah, ich meinte es eigentlich andersrum, ich meinte das du kleinere Schritte als 1/8 brauchst, ich wusste nicht das du schon ein Planetengetriebe verwendest. Wenn ein anderes Planetengetriebe nicht möglich ist hätte ich aber noch eine andere Idee: Was ist wenn du einfach vom PC aus direkt steuert? Also z.B. alle 5 Sekunden ein setSteps(1)? An der Stelle wird es dann ja nicht auf die us genau sein müssen, oder?