photron

Ist jetzt auch offiziell in Python Bindings 1.0.18 korrigiert.

Bindings: C/C++ 1.0.16, C# 1.1.9, Java 1.0.15, PHP 1.0.10, Python 1.0.18, Ruby 1.0.7 Fix direction of get_all_data_period function in Stepper Brick API Fix wrong datatype in receive thread for Python 3 (Python only) Ensure that stdint.h defines INT32_MAX (C/C++ only) Make add_device thread-safe Ensure that destroy can end the receive thread correctly (Ruby only) Ensure correct shutdown order of threads Download: C/C++, C#, Java, PHP, Python, Ruby

Bindings: C/C++ 1.0.16, C# 1.1.9, Java 1.0.15, PHP 1.0.10, Python 1.0.18, Ruby 1.0.7 Packetrichtung für get_all_data_period Funktion der Stepper Brick API korrigiert Falschen Datentyp im Receive Thread für Python 3 korrigiert (Python only) Sichergestellt, dass stdint.h INT32_MAX definiert (C/C++ only) add_device Funktion ist jetzt Thread-Safe IPConnection Destroy Funktion kann den Receive Thread jetzt richtig beenden (Ruby only) Richtige Reihnefolge beim Beenden der Threads wird jetzt eingehalten Download: C/C++, C#, Java, PHP, Python, Ruby

Callbacks werden von einem eigenen Callback Thread ausgeführt. Darfst du von einem nicht-GUI Thread mit dem GUI interagieren?

Die Device Klasse auslagern in eine eigene Unit ist nicht extern sichtbar. Als Benutzer der Bindings brauchst du IPConnection und die Unit für das jeweilige Brick oder Bricklet, der Rest ist intern.

Ich hatte das hier mit Embarcadero Delphi XE2 getestet. Kann ich tun, aber welchen Vorteil bringt das?

Ich hatte erst TSemaphore in Semaphore.pas, da aber Delphi selber schon eine TSemaphore in SyncObjs hat musst eich das umbenennen und hab beim zusammenkopieren der Dateien die alte Datei vergessen zu löschen. Ich kann hier die Delphi TSemaphore nicht verwenden, da ich die mit Timeout acquiren können muss und dass kann die Delphi TSemaphore nicht. Daher meine eigene Implementierung dafür. Richtig, das hatte ich zugesagt aber dann gestern Abend vergessen. Werde das noch hinzufügen. Dafür muss ich so virtual anhängen wenn ich es richtig verstehe. procedure BacklightOn; virtual;

Hier nun Preview 2. Dies sind die fertig generierten Bindings. delphi_preview2.zip

ah super danke, das habe ich gesucht. vllt wäre es gut, dass direkt auf http://www.tinkerforge.com/doc/Hardware/Master_Extensions/RS485_Extension.html zu verlinken. Ich habe Modbus und TCP/IP jetzt prominenter unter 'Low Level Protocol' auf der Dokumentationshauptseite verlinkt und auch einen Link zu Modbus auf RS485 Seite gepackt.

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