photron

Das Problem liegt daran, dass ich LEConvertInt8To ohne Klasse definiert habe. Der Prototyp für solche Funktionen muss in den interface Block. FPC will nun dass der interface Block der erste in einer Unit ist noch vor dem type und uses block interface procedure LEConvertInt8To(const value: shortint; const offset: longint; var data: array of byte); uses ... type ... Und jetzt nehme ich das zurück, denn ich habe beim Schreiben diese Post herausgefunden, dass der Prototype auch im type Block sein kann. Alles gut

Kann ich da so nicht tun. Da ich den type Block der TByteArray definiert nicht vor den interface Block verschieben kann. Das gibt einen Compileerror. Außerdem stelle ich gerade fest, dass ich nicht function LEConvertInt16ArrayFrom(...): array of smallint; hinschreiben kann. Ich muss für array of smallint erst einen Typ definieren. Was ich aber hier wieder nicht kann, weil der type Block nach dem interface Block stehen muss. Das zwingt mich also dazu die LEConvert Funktionen unnötigerweise in einer Klasse zu definieren. Ähnliches gilt für array [0..9] of smallint, das kann ich nicht mal als Funktionsparameter so verwenden auch dass braucht erst wieder einen eigenen Typ. Delphi/Object Pascal ist bisher die Sprache die mir persönlich am wenigsten gefällt von allen Sprachen für die ich bisher Bindings gemacht habe. Vor allem wegen dieser Sperenzchen mit den Typen Kann ich tun. Preview 1 hatte ich nicht mit FPC auf Windows getestet, das ist mittlerweile korrigiert. Ich war fälschlicherweise davon ausgegangen, dass StrToHostAddr auch einen DNS Lookup macht. Was es aber nicht tut, das ist mittlerweile auch korrigiert. Es wird heute oder morgen Preview 2 geben. Diese ist dann schon vom Generator erzeugt.

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.