borg

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.

Das geht mit der IO16 leider definitiv nicht. Auf der IO16 ist ja ein I2C Port Expander drauf, d.h. jeder Befehl muss erst per I2C übertragen werden. Damit sind solche Frequenzen leider nicht zu erreichen. Mit der IO4 sollte eine Änderung pro ms möglich sein (mehr ist mit USB nicht drin). Das reicht aber auch nicht für 256 Zustandsänderungen in 10ms.

Unfortunately there is no single protocol that is spoken over RS485 or RS232. So there is no way to use a network out of Brick stacks together with other RS485 devices. It would be possible to write a special RS485 mode that makes it possible to speak to other RS485 devices, but i have no idea if thats worth the effort.

Die dll die bei den C# Bindings dabei sind C# dlls, keine C dlls. Ich bin mir nicht sicher wie einfach das ist die aus Delphi auszurufen. Ich bin mir noch nicht mal sicher ob das überhaupt möglich ist. Eine C dll könnte man aber aus den C Bindings erzeugen. Einen Generator direkt für Delphi zu schreiben ist allerdings vermutlich trotzdem weniger Aufwand als einen Wrapper für eine C dll zu schreiben! Für ersteres sind ja schließlich schon alle Informationen maschinenlesbar vorhanden, für letzteres müsste man sich alles mit viel Zeitaufwand zusammensuchen und dann auch noch bei jedem neuen Produkt und jeder API Änderung updaten.

Die Sensoren über sehr lange Kabel direkt zu verlegen würde ich nicht empfehlen. Das kann evtl funktionieren solange keine Störungen da sind, aber da gibt es keine Garantien. Die 2m Kabel die wir verkaufen würde ich als Maximallänge empfehlen für die meisten Bricklets. Anstatt direkt die Kabel der Sensoren zu verlegen bietet sich vielleicht die RS485 Extension an: http://www.tinkerforge.com/doc/Hardware/Master_Extensions/RS485_Extension.html RS485 wird für gewöhnlich in professioneller Hausautomatisierung verwendet, das kann dann für deinen Anwendungsfall also nicht ganz falsch sein . Du würdest dann also für jeden Knoten ein Master Brick eine RS485 Extension und entsprechende Sensor Bricklets benötigen. Ich bin schon seit längeren dabei die Software für die RS485 Extension fertig zu stellen, ich hoffe sie in der nächsten Woche fertig bekomme! Sobald die Software da ist gibt es die Extension dann auch zu kaufen, die Hardware haben wir schon hier liegen in größerer Anzahl.

Die Limitierung entsteht durch USB. Eine Nachricht die einmal durch das System geht: User Programm -> Bindings (Socket) -> Brick Daemon -> USB -> Microcontroller -> Nachricht bearbeiten -> USB -> Brick Daemon -> Bindings -> User Programm benötigt ca. 1ms (dabei ist USB der begrenzende Faktor!). Sprich, die Messwerte des Analog In Bricklets können ca. 1000x pro Sekunde ausgelesen werden und das IO4 könnte eine Frequenz von 500hz messen (500x Low/500x High pro Sekunde).

Die Schnittstelle ist eine TCP/IP Verbindung! Ansonsten wäre es nicht möglich den Brick Daemon auf einem anderen Rechner als das Steuerprogramm zu haben (nur dadurch ist auch z.B. eine Steuerung vom Handy aus möglich). Die Bindings selber werden automatisch generiert aus ganz vielen Config Dateien für die einzelnen Produkte. Eine kurze Abhandlung darüber wie dies funktioniert und wie man eigene Bindings erstellen kann hab ich schonmal hier beschrieben: http://www.tinkerunity.org/wiki/index.php/BindingsErstellen Falls du oder jemand anderes aus dem Delphi Forum sich daran versuchen will stehe ich jederzeit für Fragen bereit!

Aha! Das ist ja interessant. Vielleicht ist es dann doch ein Software Fehler. Ich werde das mal am Dienstag genauso nachstellen und die ganze Software im Debug Modus laufen lassen. Ich bin gespannt. Grundsätzlich gibt es keinen Grund warum das nicht gehen sollte, also gibt es da auch einen Fix falls es an der Software liegt! Erstmal vielen Dank für deine ganzen Mühen, es ist leider immer viel Aufwand bis man solche Bugs findet die mit so vielen Elementen gleichzeitig zu tun haben.

Ich könnte mir vorstellen das eine gewissen Gefahr durch Eisbildung an den Leiterplatten besteht. Wenn es dort langfristig bleiben soll würde ich versuchen die Platinen gut einzuwickeln, so dass es keine Kurzschlüsse geben kann wenn kurzzeitig Eis auftaut weil die Kühlschranktür auf ist (das gilt natürlich vor allem für das Eisfach).

"Distance 16"? Du meinst "Distance IR Bricklet 1.0"? Das kannst du doch genauso parsen. Alles nach der ersten Leerstelle von rechts ist die Version, alles vor der zweiten Leerstelle von links ist der Name und das was überbleibt ist der Typ.