photron

Es funktioniert unter Windows wie im Hinweise am Ende diese Abschnitts beschrieben: http://www.tinkerforge.com/doc/Software/API_Bindings.html#python

Zusammengefasst: Das Schalten der Lampe um 5:05 Uhr für dazu das im Log abrupt ein "Read callback not successful (status 1): Probably disconnect" auftaucht. Danach funktioniert die Temperaturabfrage nicht mehr. Dass die Abfrage nach dem "Read callback not successful" nicht mehr funktioniert ist mir klar warum. Da ist dann die Kommunikation zwischen brickd und Master abgerissen. Das "self.alive = False" hat erstmal nicht geschadet hat aber auch nichts gebracht, weil da dann auch noch ein "Transfer exception: Probably disconnect" im Log kommt. Das "usb context broken, trying to fix it" hängt mit einem Bug in python-libusb zusammen. Es bedeute im Endeffekt, dass die unterliegende C libusb ein Problem mit dem Auflisten von USB Geräten hat. Das muss robuster werden, ich arbeite daran. In deinem Fall spielt das aber denke ich keine Rolle. Das in diesem Fall erst dass ab- und anstecken des USB Hubs es wieder zum funktionieren gebracht hat deutet darauf hin, dass sich diesmal der USB Hub aufgehängt hat. Da das jetzt schon mehrfach mit dem Schalten der Lampe zusammengefallen ist könnte das ein EMV Problem sein. Die Frage ist nun wer hier dem Empfindliche ist. Es könnte der Master sein. Nach deinem Bericht über den Hub könnte es aber auch der Hub sein und könnte es schon immer gewesen sein. Je nachdem wie stark sich der Hub verschluckt reißt mal nur die Verbindung zum Master ab, mal hängt sich der ganz Hub auf. Da kann man jetzt mehreres testen: - Master ohne Hub anschließen - Master in die Blechdose - Hub in die Blechdose Welche räumliche bzw. verkabelungsmäßige Nähe haben denn der Rechner an dem der Hub hängt, der Hub selbst, der Master, das Avocent PM10 und die Lampe?

doertom, what did you do in detail? I just tested it and it works for me as described in the note at the end of this section: http://www.tinkerforge.com/doc/Software/API_Bindings.html#python

Das kommt daher, dass in Python 3 manche Funktionen die vorher einen str Objekt zurückgegeben haben jetzt ein bytes Objekt zurückgeben und bytes und str nickt direkt kompatible sind. Du hast da eine Stelle gefunden wo wir das noch nicht richtig behandeln. Zum testen hab ich eine korrigierte Version der ip_connection.py angehängt. ip_connection.py

Du hast da eine Race Condition entdeckt. Ich denke es passiert da folgendes: Du rufst destroy() auf, der Socket wird geschlossen und der Receive Thread wird beendet. Der Callback Thread läuft aber noch weil noch was in der Callback Queue ist. Daher führt er den Callback noch aus. Im Callback rufst du get_distance() auf. Das bekommt einen Timeout weil der Receive Thread nicht mehr läuft und keine Antwort mehr ankommt. Damit das richtig funktioniert muss in destroy() zuerst den Callback Thread beenden werden und erst wenn der keine Callbacks mehr bearbeitet, dann erst kann der Receive Thread beendet. Ich hab das in der angehängten ip_connection.py so abgeändert, damit sollte das Problem nicht mehr auftreten. Kannst du das testen? ip_connection.py

Meinst du Flashen mit brickv? Wie äußerste sich diese Problem und tritt es mit der aktuellen brickv Version 1.1.5 noch auf?

SAM-BA ist jetzt raus aus der Doku. SAM-BA und brickv benutzen das selbe Interface des Microcontrollers zum Flashen. Falls es mit brickv nicht geht dann hätten wir das gerne gewusst um es verbessern zu können.

Die enable Funktion kann das schon, siehe zweiten Abschnitt hier: http://www.tinkerforge.com/doc/Software/Bricks/Servo_Brick_C.html#api servo_enable(&servo, (1 << 1) | (1 << 5) | (1 << 7)); Wenn Bit 7 gesetzt ist dann werden Bit 0 bis 6 als Bitmask interpretiert. Das Beispiel enabled Servo 1 (1 << 1) und Servo 5 (1 << 5). Alle Zählungen hier sind Null-basiert.

Okay, das ist stdint.h von hier http://msinttypes.googlecode.com/svn/trunk/stdint.h Dass heißt dann wohl, dass MSVC 2008 nocht keine stdint.h hat und du es selbst beigelegt hast. MSVC 2010 hat einen eigenen stdint.h und der braucht __STDC_LIMIT_MACROS nicht für C++. Ich geben also AuronX recht, wir bauchen hier __STDC_LIMIT_MACROS auch wenn es sich um C Code handelt. Aber unter MSVC wird der als C++ kompiliert. Ich werde das so verwenden, damit es keinen Macroredefinition Fehler gibt, falls man __STDC_LIMIT_MACROS schon als Compilerdefine setzt. #ifndef __STDC_LIMIT_MACROS #define __STDC_LIMIT_MACROS #endif #include <stdint.h>

Ich hab hier gerade nur MSVC 2010 zur Hand und da ist stdint.h vollständig. Kannst du mir deine MSVC 2008er stdint.h zukommen lassen, z.B. durch Anhängen an einen Post? Sollte ca. hier zu finden sein: C:\Program Files\Microsoft Visual Studio 9.0\VC\include

Mit welchem Compiler ist das?

Im Brick Viewer auf dem IMU Tab unten links den Calibrate Button klicken. Im Calibrate Fenster den Im/Export Tab auswählen. Die Kalibrierungsdaten aus der Textdatei in das Textfeld pasten und Import klicken. Fertig

So 1.1.5 ist raus. Ich hatte in 1.1.4 einen Check eingebaut ob der Serielle Port schreibbar ist. Dabei hatte ich dummerweise nicht darauf geachtet, dass das so auf Windows nicht funktionierte, sondern nur unter Linux.

Brick Viewer 1.1.5 Don't change selected serial port on refresh when possible Fix serial port writability check on Windows, flashing Bricks works again Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.5 Der ausgewählte Serielle Port wird beim Refresh wenn möglich nicht verändert Schreibbarkeitstest für Serielle Ports auf Windows korrigiert, Flashen von Bricks funktioniert wieder Downloads: Windows, Linux, Mac OS X

Ah, ich sehe wo das Problem ist. Gibt dann in kürze 1.1.5, bis dahin kannst du mit 1.1.3 flashen, da ist's noch heile

Benutzt du Brick Viewer 1.1.4? Falls nicht update und versuchs noch mal. In der Version habe ich die Fehlermeldungen detaillierter gemacht. Das die Dropdownbox auf den ersten Eintrag zurückspringt ist ein Bug, aber nicht die Ursache des Problems hier.

Komisch warum du da root Rechte zu brauchst. Auf Ubuntu 11.10 hier gehört /dev/ttyACM0 der Group dialout und ich bin Member dieser Group. Das war automatisch so ohne mein zutun. Hast du da vielleicht SELinux laufen? Wie dem auch sei, Brick Viewer 1.1.4 meldet jetzt in diesem Fall statt einfach nur

Brick Viewer 1.1.4 Add monoflop GUI for the Dual Relay Bricklet plugin Improve error reporting for inaccessible serial port Add reset buttons for Bricks Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.4 GUI für Monoflop Funktion des Dual Relay Bricklets hinzugefügt Verbesserte Fehlermeldungen für Probleme mit Seriellen Ports Resetknöpfe für Bricks hinzugefügt Downloads: Windows, Linux, Mac OS X

Hast du schon versucht die 3 betroffenen Bricks noch mal absichtlich in den Bootloader zu versetzen?

brickv liegt im drivers Verzeichnis der richtige Treiber bei: atm6124_cdc.inf Bzw. Windows hat den Treiber schon dabei (usbser.sys, USB Serial Device). Die .inf Datei sagt Windows nur noch dass das USB Gerät mit Vendor und Product ID XYZ mit usbser.sys zu verwenden ist. Windows 7 findet wohl irgendwie zu der Vendor und Product ID der Bricks den Eintrag für eine GPS-Kamera. Das Flashen funktioniert aber auch wenn Windows den falschen Namen findet?

Exakt für solche Fälle ist der 5V Ausgang gedacht.

Das wurde schon mal hier diskutiert. http://www.tinkerunity.org/forum/index.php/topic,445.msg2275.html Die nächste Version der LCD Bricklet Platine wird eine einfachere Möglichkeit bieten externe Taster anzuschließen. Für einen 4. Taster ist leider kein Pin mehr frei. Das ist auch der Grund warum es gerade 3 Taster sind.

Na... 1.1.3 hatte es eh geben müssen für RS485, das ist keine Bugfix Version. Aber 1.1.2 hätte aber auch mit der neuen Master Firmware funktionieren sollen.