borg

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!

Habs mir gerade kurz angeguckt, das ist leider gar nicht so einfach. Der Timer Counter den wir verwenden um die Schrittgeschwindigkeit zu bestimmen hat eine maximale Laufzeit von unter 2 Sekunden. D.h. ich müsste da anfangen mitzuzählen und nur jedes x-te mal ein Schritt machen etc. Das ist technisch natürlich möglich, kann ich aber nicht mal gerade so auf die Schnelle implementieren. Ich hab es mir aber auf die TODO Liste geschrieben. Ist die Bewegung der Kamera nicht relativ ruckartig bei 1/8 Schritten? Würde es nicht in deinem Fall sowieso mehr Sinn machen da noch eine Untersetzung einzubauen damit die Kamera sich ruckfreier bewegen kann? Langsamer würde sie dadurch dann ganz automatisch werden!

Wenn du schon eine IO4 hast kannst du denke ich auch einen einfachen Spannungsteiler bauen, so wie hier: http://www.mikrocontroller.net/articles/Datei:Pw_st_5-3.png Das zieht dann natürlich ein bisschen mehr Strom.

Ich kenne mich mit VCL leider nicht aus, aber kannst du nicht einfach eine Funktion wie "setLabelText" aus dem Callback heraus aufrufen? Also sowas wie: class Beispiel { public: callback(int16_t position); // Ruft setLabelText(toStr(position)) auf setLabelText(string str) // Setzt Text in label private: VCLLabel label; } Die eigentliche Frage hier ist ob ein Label in VCL Thread safe ist, falls nicht musst du die Position zwischenspeichern und aus dem GUI Thread heraus den Wert setzen!

Ich würde nicht ausschließen das wir sowas mal bieten, aber vermutlich nicht in den nächsten Monaten. Das einzige was mir dazu gerade einfällt ist sowas hier nehmen: http://www.pollin.de/shop/dt/MDY5OTE4OTk-/Bauelemente_Bauteile/Aktive_Bauelemente/Sensoren_Peltier_Elemente/Kabelfuehler_mit_NTC_Sensor_10_k_2_m.html und mit dem Analog In Bricklet auslesen (da muss dann natürlich noch eine kleine Schaltung zwischen )

Ah, ich meinte nicht die Interrupt Zeit die du extern setzt, die ändert nichts daran wie schnell ich die Temperatur intern auslesen. Das sollte an der Stelle also egal sein. Im gegenteil, um zu testen ob der Fehler noch auftritt macht es wahrscheinlich Sinn die Interrupt Zeit möglichst klein zu machen .

Das kann man so ohne weiteres leider nicht beantworten, das ist von vielen Faktoren abhängig. Besonders bei den Bricklets die I2C zur Kommunikation nutzen (das sind im Moment die LCD Bricklets, Temperatrure Bricklet, Temperature-IR Bricklet und IO16) würde ich allerdings 2m schon als definitives Maximum ansehen.

OK, da bleibt dann als Fehlerursache wohl nur die Länge des I2C Busses über. Der Temperatursensor auf dem Temperature Bricklet wird über I2C ausgelesen (die anderen von dir verwendeten Bricklets benutzen kein I2C, daher der Fehler nur beim Temperature Bricklet). Die Länge des I2C Busses setzt sich zusammen aus der Summe alle angeschlossenen Bricklet Kabel. Dazu fallen mir mehrere Ideen ein: [*]Kürzere Kabel verwenden (geht wahrscheinlich nicht) [*]Das Temperature Bricklet mit einer geringeren Frequenz auslesen, die Temperatur ändert sich ja nicht jede ms, da muss also nicht unbedingt die volle Geschwindigkeit genutzt werden [*]Die Temperatur immer mehrfach auslesen und Ausreißer aussortieren Ich hab mal auf die Schnelle eine Firmware gemacht welche die Temperatur mit 100khz statt 400khz ausliest: http://download.tinkerforge.com/_stuff/temperature-bricklet-100khz.bin Das könnte die Probleme schon beseitigen, ich tendiere aber gerade dazu auf dauer Möglichkeit 3 zu implementieren. Das muss ich dann aber vernünftig testen damit ich nicht mehr Fehler reinbaue als ich fixe . Gucke ich mir dann am Dienstag oder Mittwoch an.