borg

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?

Die Spannung für die Ausgänge ist nicht einzeln einstellbar und er möchte 2 unterschiedliche Spannungen.

Jop, Danke für den Tipp. Der 915Mhz Bereich fängt bei Channel 1 an (statt 0 wie bei den anderen Frequenzen). Da fehlt einfach ein +1 im Brick Viewer Code. Habs gefixt, werde in nächster Zeit sowieso eine neue brickv Version hochladen (mit RS485 support), da ists dann gefixt. Gleich zwei Bugs auf einmal gefunden, nicht schlecht .

OK, interesting. Thank you for the help, will look into that tomorrow again. I probably will have to set up a fresh OS X install in a VM for that, something fishy is going on, because it works here .

Die sind alle unter Zubehör Edit: Ah, ich sehe was das Problem ist. Die meisten Produkte unter Zubehör -> Verbinder waren nur da und nicht direkt unter Zubehör. Deswegen waren sie vermutlich schwer zu finden. Hab sie mal direkt hinzugefügt. Die Hardware der RS485 Extension ist noch aus der ersten Produktion, die leider Qualitätsprobleme hatte. D.h. wir müssen die definitiv alle testen bevor wir die verschicken und das können wir erst vernünftig wenn die Software fertig ist .

Thats confusing. Did you remove brickd.log before you started brickd again? The error really shouldn't be there anymore, perhaps it is still a log from the earlier tries? Have you tried to start it with launchctl? sudo launchctl start com.tinkerforge.brickd

da fehlen ja wirklich die zwei Funktionen! Bei mir lokal waren sie drin und es hatte lokal die gleiche Version wie die letzte online. Bin gerade durchgegangen, es fehlten überall die Funktionen außer bei den Python Bindings. D.h. ich muss überall alles geupdatet haben und dann aus irgendwelchen Gründen habe ich nur die Python Bindings hochgeladen. Oh man . Probier es nochmal mit der neuesten Version: http://download.tinkerforge.com/bindings/java/

Ich habs jetzt nicht explizit getestet, das sollte aber gar kein Problem sein. Als Abhängigkeiten musst du python-twisted, python-gudev und libusb-1.0-0 installieren, dann den Code von https://github.com/tinkerforge/brickd clonen, dann in den Ordner brickd/src/brickd wechseln und mit python brickd_linux.py als root starten, fertig. Wenn es Probleme gibt kannst du mit python brickd_linux.py nodaemon starten und in der config.py das logging auf DEBUG stellen.

Welche Version der Bindings nutzt du denn? In 1.0.3 sind bei mir die ganzen Funktionen da in der BrickMaster.java: http://download.tinkerforge.com/bindings/java/

Alright, new version is up: http://download.tinkerforge.com/tools/brickd/macos/ please report if it is working!

Phew! After the update to 10.7 brickd did indeed not work anymore. But we already found the problem. On OS X 10.7 the standard unix double fork trick (to make daemons) does't work anymore if some core libraries are already included. Totally weird if you ask me. We should be able to upload a fixed version shortly!

Gut zu wissen das es so funktioniert! Dann sollten wir wohl noch was zu Kabellänge und I2C in die Doku schreiben. Zu deiner Frage: Das werde ich so nicht in die normale Firmware übernehmen, ganz einfach weil da jetzt zuviel Zeit für die Kommunikation mit dem Temperatursensor drauf geht. Das ist beim Master Brick egal, bei Bricks die viel berechnen (z.B. IMU Brick) kann das aber kritisch sein. Ich schreib hier nochmal wenn ich eine Lösung implementiert habe mit der ich rundum zufrieden bin :-). Kannst du dann ja nochmal testen, wenn du lust hast.

Unortunately we still have 10.6.8 on the Mac we are using for testing. We expect hat the problems have something to do with 10.7, you are not the only one with problems there. I am currently updating our MacBook, i will report back as soon as i know more!