borg

Ah, verstehe. Mhhh. Also grundsätzlich solltest du es folgendermaßen Parsen können (Pseudocode): liste = name.split(" ") version = liste.last(); liste.remove_last() type = liste.last(); liste.remove_last() name = liste.join() Sprich: Am Ende steht der Name, davor kommt der Typ (mit Leerstelle getrennt), dann kommt der Name (zwischen Typ und Name auch mit Leerstelle getrennt, aber der Name selber kann Leerstellen enthalten). Aber: An der Stelle gibt es folgendes zu beachten: Die Versionsnummer ändert sich nur wenn die Hardware inkompatibel geworden ist. D.h. auch bei den ganzen neuen 1.1 Hardwareversion wird dort 1.0 stehen. D.h. du kannst damit nicht herausfinden ob die Platinen glänzend oder Matt sind (was der Unterschied zwischen Stepper Brick 1.1 und 1.0 ist). Ich hoffe das macht irgendwie Sinn. Wir wollen eigentlich nicht 1000 unterschiedliche Firmwares machen für Hardware die die gleiche Schaltung hat.

Das ist komisch. Wenn du einen anderen Master da hast probier den doch mal bitte. Sonst würde das ja bedeuten, dass der Temperatur-Mess-IC auf dem Temperature Bricklet einen defekt hat (wenn er nicht richtig angelötet wäre o.ä. hättest du definitiv eine höhere Fehlerquote). Hast du denn ein größeres System am laufen (zum testen jetzt)? Wenn ja probier doch mal eine Zeit lang nur den Master mit einem Temperature Bricklet laufen zu lassen! Vielleicht hat es ja mit der Kombination von irgendwas zu tun.

Ha, an sowas hatten wir beim ersten Design der Hardware in der Tat schon gedacht. Es gibt im Stack einen sync Pin (siehe Schaltplan). Damit wäre es in Theorie möglich genau das zu machen was du vorgeschlagen hast. Was ich mir da vorstelle ist eine Methode "trigger()" mit der man diesen Pin triggert. Dazu müsste es dann bei jedem Brick eine Methode "setTriggerType" geben bei der man setzen kann was getriggert wird damit (z.B. step() beim Stepper Brick). Ich schreib es mal auf meine TODO Liste, komme aber vermutlich frühestens Ende des Monats dazu das zu implementieren.

Ich kann das Problem bei mir nicht erzeugen. Hab es über Nacht laufen lassen (~6 Stunden) sowohl mit einem 2m als auch mit einem 15cm Kabel. Das erste was ich dann jetzt probieren würde ist ein kürzeres Kabel. Um zu gucken ob es am langen Kabel liegt.

So, ich hab mal alles an Messgeräten was wir hier haben angeschlossen und rumprobiert. Grundsätzlich ist es so, dass sich der Strom im Durchschnitt nicht besonders ändert zwischen halten, frei laufen und unter Last. Ich gehe davon aus dass dein Messgerät unterschiedliche Werte anzeigt weil der Stepper Brick unterschiedlich chopped (mit und ohne Last etc). Kannst du vielleicht unterschiedliche "Mess-Modi" einstellen? Wegen den weitläufigen Werten: Was du da siehst ist auch das Chopping, Der Schrittmotor wird angetrieben indem er immer abwechselnd volle Leistung/0A bekommt. Ich hab mal eine neue Firmware hochgeladen: http://download.tinkerforge.com/firmwares/bricks/stepper/ (1.1.3) Der Stromverbrauch wird jetzt über ein kleines Integral berechnet, so wie es jetzt ist stimmt der Wert zu jeder Zeit mit dem Messgerät überein was ich hier hab (+-15mA). Ich denke das ist erheblich sinnvoller als diskrete Werte zurück zu geben, wie wir es vorher hatten. Damit man die auswerten kann braucht man vermutlich zuviel Kenntnis von dem Schrittmotor Treiber IC den wir verwenden. Wenn es geht probier doch mal die neue Firmware aus und sag Bescheid ob die Werte eher so sind wie du dir vorgestellt hast.

Ich konnte das Problem hier bisher noch nicht erzeugen, auch nicht mit einem 2m Kabel.

Oh, das ist komisch. Wir schicken ja mit CRC und überprüfen die auch. Ist es für dich möglich zu testen ob dieses Problem auch ohne Chibi auftritt? Vor allem die gleiche Bricklet-Kabellänge verwenden! Bei Messungen alle 10 Sekunden ist das eine Fehlerrate von ~0,5% wenn ich mich nicht verrechnet hab. Das so oft ein Fehler auftreten soll der durch die CRC Prüfung rutscht kann ich mir gar nicht vorstellen. Welche Version haben deine Master denn? Wir haben in letzter Zeit viel am Chibi Code gearbeitet, die neueste Version ist 1.1.7: http://download.tinkerforge.com/firmwares/bricks/master/ Ich werde das hier mal nachstellen und über Nacht laufen lassen, mal gucken was dabei rum kommt.

Die ganzen Bindings sind komplett autogeneriert und die Konfigurationsdateien wo die Informationen für die Generierung herstammen findest du hier: https://github.com/Tinkerforge/generators/tree/master/configs für den Stepper Brick z.B. hier: https://github.com/Tinkerforge/generators/blob/master/configs/brick_stepper_config.py Mhhh, das ist im Moment leider nicht möglich. Die Informationen sind auf dem Master Brick alleine leider auch nicht alle vorhanden. Der Master könnte einer Stack ID den Platz in der Platine zuweisen (z.B. dritte Platine von unten). Alle Bricks könnten einer Stack ID von einem Bricklet den Port zuweisen. Stellt sich natürlich die Frage wie man dafür eine vernünftige API macht, muss ich mal drüber nachdenken. Kurz zur Erklärung: Der Master enumeriert sich erst selbst durch (seine Bricklets). Dann enumeriert er alle Stack Teilnehmer durch (und übergibt als startende Stack ID die momentan höchste Stack ID). Dann enumeriert er alle Extension Teilnehmer durch. Der Master der Extension seinen Stack schon enumeriert und es wird nur noch ein Offset in der ID übertragen. Wenn nun eine Nachricht mit Stack ID x ankommt, weiß der Master der per USB angeschlossen ist genau wo die hin muss (z.B an die Extension oder an den Stack Teilnehmer Nummer y). Er weiß aber nicht was es für ein Typ ist oder an welchem Port ein Bricklet sitzt o.ä. Da haben wir elektronisch keinen "Detection Pin" o.ä., das einzige was du machen kannst ist GetVoltage auf dem Master aufrufen. Wenn die Spannung ungleich 0 ist, ist eine Step-Down Powersupply da.

Oh, das ist ein "Bug". An der Stelle ist das aber natürlich egal, der Wert wird ja nicht benutzt. Wenn ich das nächste mal etwas an den Bindings ändere werde ich das fixen.

Echt komisch, sieht alles so weit gut aus. Als length würde ich 12 erwarten anstatt 14, das sollte aber keine Probleme machen. Ich hab mal das Testprojekt was wir hier verwendet haben hochgeladen: http://download.tinkerforge.com/_stuff/project_uwet.zip Bin gespannt ob das bei dir funktioniert. Wenn ja müsste es irgendeine Compilereinstellung o.ä. in deinem Projekt sein sein die zu den Problem führt. Du kannst auch versuchen die Test.exe direkt auszuführen, das sollte auf jedenfall gehen. Wenn die nicht geht liegt das Problem außerhalb des Compilers, da sie bei uns funktioniert. Als UID haben wir 94ANbHiaKXq genommen das sollte die für deinen Stepper Brick sein.

Mysteriös. Wo steht er denn bei ipcon_add_device (Zeie 339ff)? Kommt er bis zum if(ipcon_answer_sem_wait_timeout(device) != 0) { oder steht er schon beim send(ipcon->s, (const char*) &gsid, sizeof(GetStackID), 0); ? Und kannst du da auch mal die Elemente von GetStackID ausgeben? Um zu gucken ob da alles richtig ist.

Brick Viewer and Brick Daemon for Mac OS X are now online: http://en.blog.tinkerforge.com/

It is fairly simple. We have a Brick Daemon, a Brick Viewer and language bindings. The daemon has a USB connection to the Bricks (and over the Bricks to the Bricklets) and opens a TCP port. The bindings (currently for C/C++, C#, Java, Python) speak over TCP with the Brick Daemon and provide an API to the user (like SetSpeed, GetTemperature, etc). That is in principle all you need to use Bricks and Bricklets (the Brick Daemon and one language binding). Additionally we have the Brick Viewer, that provides a GUI for all of the API for all Bricks/Bricklets. The idea is to use it for testing before you start your own project. A list of devices that we currently have can be found here: http://www.tinkerforge.com/doc/index.html#bricks You can click on the names to get an in depth description.

Sehr unwahrscheinlich das es am Rechner selbst liegt. Wird denn die Funktion ipcon_recv_loop überhaupt aufgerufen? Also wenn du mal ein printf direkt oben in Zeile 38 reinmachst. Ansonsten, gestartet wird die recv loop in Zeile 293: ipcon->handle_recv_loop = CreateThread( NULL, 0, (LPTHREAD_START_ROUTINE)ipcon_recv_loop, (void*)ipcon, 0, (LPDWORD)&thread_recv_loop_id ); Wird da noch aufgerufen? Wenn nicht, wo bleibt das Programm stehen vorher? Dem Problem sollten wir auf die Spur kommen können, soviel passiert ja gar nicht bis dahin.

Mh, schwer zu sagen. Da im brickv jetzt alles funktioniert, scheint der brickd ja zu laufen. Der brickv nutzt zwar Python, aber die Kommunikation läuft ja über herkömmliche Sockets. Ich würde also ausschließen das die nicht richtig funktionieren. Bleiben nur noch die C Bindings selbst übrig. Kannst du mal den buffer in der ip_connection.c direkt in der recv loop ausgeben (Zeile 61)? Ich würde im Moment davon ausgehen das die Daten dort ankommen (da ich einfach keinen Grund sehe warum es nicht funktionieren sollte), dann aber irgendwo in einer der Semaphoren oder so stecken bleiben. Ich würde erwarten das die Nachricht an ipcon_handle_message übergeben wird, dort wird festgestellt das der Typ TYPE_GET_STACK_ID ist, von da gehts an ipcon_add_device_handler und da wird die sem_answer Semaphore freigegeben. Wenn es geht guck doch mal wo es da stecken bleibt, da es bei uns läuft hab ich da gerade keinen Anhaltspunkt woran es liegen könnte.

They would fit there, but the connectors of the Bricklet cables would collide with the USB connector on a USB cable (about 1mm with the cables we are currently selling).

A Brick with more than 4 Bricklet connectors is quite hard. Bricks are defined to have a size of 4x4cm, 2 board-to-board connectors at the sides and one usb connector and 2 buttons at the front. 4 Bricklet connectors are unfortunately the maximum that can be mounted on the back side. A larger board without stack capability with just a USB connector and lots of Bricklet connectors would be possible. A Multi Analog IN Bricklet would also be possible. I doubt that we will make any of the two in the next months however. There is so much more stuff we want to release, we have to prioritize. Regarding the mounting kits: Mhh, i suppose the idea is that you get everything you need to be able to place a Brick/Bricklet on a table without the board touching it. It is hard to provide anything that might be needed to mount our stuff in any possible casing or similar. That said, you can probably buy 3mm screws for something like 1 cent/piece at your local hardware store. Also we intend to offer casings for all of our Bricks/Bricklets in the future, there you will of course get anything needed.

Bei mir funktioniert der Source Code hier: https://pastee.org/gtnxq sowohl unter Linux (Ubuntu 11.10) als auch unter Windows 7 ohne Probleme. Hast du die IO16 schon auf die neueste Firmware geupdatet? Hab da vor kurzem eine Kleinigkeit hinzugefügt, siehe hier: http://www.tinkerunity.org/forum/index.php/topic,188.0.html (das kann aber eigentlich nichts mit deinen Problemen zu tun haben) Funktioniert das denn im Brick Viewer? Einfach starten und auf die Knöpfe drücken, der konfiguriert dafür standardmäßig genau richtig. Welche Version haben deine Python Bindings? http://download.tinkerforge.com/bindings/python/

Oh, es leuchtet keine LED wenn du es per USB anschließt? Aber es taucht ein neues Gerät unter Windows auf? Klingt als wäre dein Servo Brick im Bootloader! Dann musst du eine neue Firmware draufflashen, wie das geht ist hier beschrieben: http://www.tinkerforge.com/doc/Software/Firmwares_And_Plugins.html#flash-firmware-on-a-brick Firmware fürs Servo Brick gibts hier: http://download.tinkerforge.com/firmwares/bricks/servo/

OK, nochmal zum Thema Kalibrieren (das Kalibrieren unter "advanced functions"). Wenn man dort auf "calibrate" klickt, werden die Extremwerte des Analog zu Digital Wandlers vom Brick kalibriert. Das hat an der Stelle erstmal überhaupt nichts mit den Bricklets zu tun! Nun, um die Extremwerte (d.h. 0V und 3.3V in unserem Fall) zu kalibrieren, benötigen wir aber extern etwas, das diese Werte erzeugt. Da kommen die analogen Bricklets ins Spiel. Um den Analog zu Digital Wandler korrekt zu kalibrieren müssen wir also ein Bricklet anschließen mit dem wir auf dem analogen Pin 0V und 3.3V erzeugen können, dies geht z.B. gut mit den Potis. Dazu kann man ein Poti anschließen, auf einen Extremwert drehen, "calibrate" klicken, auf den anderen Extremwert drehen, "calibrate" klicken und fertig. Nun sind 0V und 3.3V kalibriert. Diese Möglickkeit haben wir eingebaut da der Analog zu Digital Wandler auf dem Microcontroller nicht immer die vollen Werte erreicht. Da er eine 12 Bit Auflösung hat sollte er bei 0V 0 ausgeben und bei 12V 4095. Allerdings kann es sein das er sowas wie 2 und 4092 o.ä. ausgibt, dieser Fehler wird Kalibriert. Wenn du den Analog zu Digital Wandler nun verkalibrierst (d.h. du drückst z.B. "calibrate" wenn das Poti nicht nach ganz links oder ganz rechts gedreht ist), gibt alles falsche Werte zurück was den Analog zu Digital Wandler benutzt. Unter anderem alle Analog Bricklets und die Spannungs- und Strommessung im Stack! Um das nochmal ganz klar zu machen: Diese Kalibrierung wird auf dem Brick gespeichert und betrifft das Brick, das Bricklet mit dem kalibriert wird ist nur Hilfsmittel. Wenn du aus welchen Gründen auch immer Probleme mit der Kalibrierung hast, würde ich sehr stark empfehlen das Brick neu zu flashen und einfach den "calibrate" Knopf unter "advanced functions" nicht zu drücken . Zum Thema Lux: Tageslicht hat 10000 Lux, dein Handy kann vermutlich 900 Lux erzeugen wenn du es genau drauflegst. Zum Thema Ambient Light Kalibrieren: Das muss nicht kalibriert werden, wenn du etwas mehr über die genauen Eigenschaften des Sensors erfahren willst kann ich dir die Graphen im Datenblatt empfehlen: https://github.com/Tinkerforge/ambient-light-bricklet/raw/master/datasheets/TEMT6000.pdf Edit: Die Bricklets die eine Kalibrierung benötigen (z.B. Current oder Distance IR) haben Kalibrierungsfunktionen dafür im jeweiligen Bricklet Fenster im Brick Viewer. Diese Kalibrierungen werden dann natürlich auch auf den Bricklets gespeichert.

Überprüfen welchen Interrupt du bekommen hast kannst du mit dem binären &, z.B.: if value & (1 << 5): # hier code für pin 5 = high if value & (1 << 0): # hier code für pin 0 = high # ... Ansonsten, ist mir noch nicht klar was du machen möchtest. Soll der Motor so lange fahren wie du den Knopf drückst? Dann würde ich machen # Schalter an Pin 5 if value & (1 << 5): stepper.drive_forward() else: stepper.stop() Wenn du pro Knopf drücken x Schritte fahren willst: # Schalter an Pin 5 if value & (1 << 5): stepper.set_steps(x)

Naja, dafür musst du die Schrittanzahl die beim Poti eingestellt wird zwischenspeichern und sobald du den Callback bekommst den Wert mit set_steps setzen.

Puh, schwer zu sagen. Der Brick Viewer ist ja in reinem Python geschrieben, da sollte man so einfach eigentlich gar keinen Speicherzugriffsfehler erzeugen können. Vielleicht ein Bug in der Qt oder PyQt Version von Ubuntu 12.04? Der strace ist leider nicht besonders hilfreich. Wenn du lust hast kannst du mal in der mainwindow.py in MainWindow.__init__ (ab Zeile 67ff) Stück für Stück ein "return" einbauen und gucken ab welcher Zeile der segfault kommt. So wie der strace aussieht passiert das vermutlich entweder schon beim setupUi oder sogar direkt beim import oben. Ob die imports gehen kannst du testen in dem du einfach python in der Console startest und die import zeilen dort ausführst: from PyQt4.QtCore import pyqtSignal, QAbstractTableModel, QVariant, Qt from PyQt4.QtGui import QMainWindow, QMessageBox, QIcon

Du meinst 1.0.6 oder? 1.0.7 gibts nicht . Unter 11.10 hab ich das .deb gerade nochmal getestet, läuft. Um den Brick Viewer aus den Sourcen zu starten musst du einmal build_all_ui.py (im src/brickv/ Verzeichnis) ausführen und vorher pyqt4-dev-tools installieren. Das baut die GUI aus den .ui Dateien. Und dann wenns geht einmal in der config.py auf logging.DEBUG stellen und nochmal main.py ausführen. Dann bitte die Ausgabe hier nochmal posten, bin gespannt was der Fehler ist.

Hab mir mal gerade den IO16 Code kurz angeguckt. Das kann Zustande kommen wenn uns der IO Expander ein Interrupt erzeugt während wir in der debounce Phase sind (low -> high), dann das Interrupt wieder wegnimmt (high -> low) und dann ein neues Interrupt kommt (low -> high) bevor die debounce Phase zuende ist. Ich hab mal eingebaut das der letzte Interrupt gespeichert wird um zu gucken das wir den gleichen nicht nochmal verarbeiten: https://github.com/Tinkerforge/io16-bricklet/commit/147ad1f617c766313edaf5461f9eee5efe498b25 Ob das dein Problem zu 100% löst kann ich nicht sagen, schaden tut es aber nicht. Hier gibts die neue Version: http://download.tinkerforge.com/firmwares/bricklets/io16/bricklet_io16_firmware_1_1_1.bin