photron

Du hast da einen Bug in den Python Bindings gefunden (cannot join current thread). Der ist jetzt in Version 1.0.11 behoben. Das ist aber nicht dein eigentliches Problem, sondern nur ein Nebeneffekt. Teste doch noch mal bitte mit den aktuellen Python Bindings. Was mir noch in deinem Code auffällt: Du registrierst den Callback für den Interrupt bevor du das DC Brick Objekt erzeugst. Du greifst aber im Callback auf die dco Variable zu. Es kann also passieren dass ein Callback kommt bevor die dco Variable richtig gesetzt wurde. Mit anderen Worten: Änder doch mal bitte die Reihenfolge von io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection zu dco = DC(UID_DCo) # Create dc brick device object ipcon.add_device(dco) # Add device to IP connection io4.register_callback(io4.CALLBACK_INTERRUPT, cb_interrupt) einfach um da auf der sicheren Seite zu sein. Oder prüfe im Callback ob dco != None ist bevor du es verwendest.

In den aktuellen Bindings Versionen (C/C++ 1.0.8, C# 1.1.2, Java 1.0.8, PHP 1.0.3 und Python 1.0.9) wird jetzt auch der Device Typ überprüft. Für einen erfolgreichen AddDevice Aufruf muss jetzt ein Device mit passendem Typ und UID antworten.

Okay, dieses Python 3 Problem ist in Python Bindings 1.0.8 jetzt behoben.

Ich habe jetzt die Beispiele in der TCP/IP Dokumentation noch etwas mehr mit den Typen der Bestandteile eines Packets versehen und ein weiters Beispiel für die kurze UID eines Bricklets hinzugefügt.

Dass das so halb funktioniert wenn du nur Bricklets mit dem zu kurzen Request anfragst hat mit einem Implementierungsdetail der Firmware zu tun und ist im Prinzip zufällig. Es hätte nur für den Master funktionieren sollen und für die Bricklets nie, wegen des zu kurzen Requests. Auch dass das mit den Bricklets nicht mehr geht sobald du einmal den Master angefragt hast beruht auf dem selben Zufall. uint64 -> immer 8 Byte Ich werds etwas deutlich ins Beispiel schreiben im Sinne von "UID 3904673860505581361 as uint64 (0x31 0x37 0x30 0x33 0x30 0x30 0x30 0x36)." Und noch ein Beispiel für ein Bricklet machen. Allgemein gilt: Im TCP/IP Protokoll hat alles feste Größen. Nichts besonderes sollte es mit hex "20" auf sich haben. Auch ist das kein Füller denke ich. Für die Bricks kommt die UID aus dem Mikrocontroller selbst und wir benutzen die einfach, Typischerweise sind dass immer Zahlen bei denen alle 8 Byte der uint64 ungleich 0 sind. Für die Bricklets zählen wir selber eine eindeutige Nummer hoch die dann im EEPROM gespeichert wird. Die erste Bricklet UID war dabei so gewählt das sie in Base58 3-stellig ist und es auch noch eine Weile bleiben wird.

Ohne das jetzt zu testen oder mir über netcat Gedanken zu machen sehe ich hier schon ein Problem. Ein IPConnection.get_stack_id Request Packet hat immer 12 Byte, da die UID fest 8 Byte gross ist. Das heisst [00 FF 06 00 62 57] muss [00 FF 0C 00 62 57 00 00 00 00 00 00] sein.

Ich hab's gerade mal getestet mit Processing 1.5.1 auf Linux und man kann wohl einfach die Java Bindings nehmen. Hier mal was ich getan habe. Mein Processing Sketchbook Verzeichnis ist ~/sketchbook. Darin dann Verzeichnisse anlegen so dass sich ~/sketchbook/libraries/Tinkerforge/library/ ergibt. Darein dann die Tinkerforge.jar, also: ~/sketchbook/libraries/Tinkerforge/library/Tinkerforge.jar Hier ein minimales Proof-of-Concept Beispiel, dass zeigt das zumindest das Import funktioniert: import com.tinkerforge.*; IPConnection ipcon; void setup() { try { ipcon = new IPConnection("localhost", 4223); } catch (Exception e) { } } void draw() { }

Ich hab gerade noch ein Problem mit den Callbacks behoben. Wenn du in einem Callback einen Getter des selben Devices aufgerufen hast konnte das zu einer TimeoutException führen. Das ist in PHP Bindings Version 1.0.2 jetzt behoben. Zu deinem Problem: Dein Script erzeugt in jeder connect_* Funktion eine neue IPConnection. Du solltest initial nur eine erzeugen un die dann in allen connect_* Funktion verwenden. So wie dein Script jetzt ist dispatcht du Callbacks nur auf der zuletzt erzeugen IPConnection der du nur das Temperature Bricklet hinzugefügt hast. Ich denke das erklärt dein Problem

Super. Das ist aber neu, oder? Vor ein paar Wochen habe ich das noch nicht gefunden. Recht neu noch, ja 30. April => http://de.blog.tinkerforge.com/2012/4/30/low-level-protokoll-dokumentierung

PHP hat keine Threads. Das führt erstmal dazu, dass du selbst dispatchCallbacks() aufrufen musst. Wenn du dispatchCallbacks(1) dann werden eingehende Daten vom Socket gelesen und wenn es sich um Callbacks handelt werden diese ausgeführt, falls dafür Funktion registriert wurden. Wenn du dispatchCallbacks(1) aufrufst, dann wird das eine Sekunde lang gemacht und dispatchCallbacks(1) returned auch erst nach einer Sekunde. Das heißt das dein Script an der Stelle für eine Sekunde "steht". Du kannst auch dispatchCallbacks(0) aufrufen, dann werden nur die gerade verfügbaren Daten vom Socket gelesen ohne noch eine Sekunde auf weitere Daten zu warten. Daher empfehlen ich dir dispatchCallbacks(0) aufzurufen. Du solltest weiterhin darauf achten dass du keine lange dauernden Dinge in den Callback Funktionen machst.

Die Callbacks sind in Java per Listener realisiert. Aber die Callbacks werden vom Device ausgelöst. Ein wichtiger Aspekt von Callbacks ist, dass du eben nicht pollen musst, sondern das Device es von sich aus sendet. Das spart deutlich an USB Bandbreite. Aber du kannst natürlich in deinem eigenen Code einen Thread starten und Stack Voltag und Current pollen

Nein, die Callbacks für den Master sind nicht drin, das würde eine Änderung der Firmware benötigen. Ja, Java Bindings Version 1.0.7 beinhaltet JavaDoc (siehe changelog.txt in .zip). Das ist allerdings noch nicht ganz perfekt, da z.B. die einzelnen Funktionsparameter nicht explizit dokumentiert sind. Das gibt der Bindings Generator im Moment nicht her.

Zum Beispiel RealBASIC unterstütz Sockets. Dadurch kann man potentiell RealBASIC Bindings erstellen. Aber nimm das jetzt nicht als Ansage das es in nächster Zeit RealBASIC Bindings geben wird

In Java Bindings 1.0.7 gibts keine unnötigen addListener Methoden mehr.

In C# Bindings Version 1.1.1 gibt es jetzt XML Dokumentation. Auch die anderen Bindings haben jetzt Inline Dokumentation.

Im Moment bin ich mit generellem Aufräumen beschäftigt. Die nächsten Bindings werden für Ruby. Also keine Sorge, dass wir da morgen fertige Delphi Bindings präsentieren. Sind deine Delphi Bindings bisher von Hand programmiert oder hast du auch schon einen Generator gebaut? Am liebsten wäre es mir natürlich wenn ich für die zukünftigen offiziellen Delphi Bindings auf deine bisherige Arbeit aufsetzen könnte

Ich hab die addListener/registerCallback Methoden entfernt für Devices die keine Callbacks haben. Die Callbacks für den Master sind eine gute Idee.

Die TCP/IP Dokumentation ist schon fertig. Hier der generelle Teil http://www.tinkerforge.com/doc/Software/IPConnection_TCPIP.html#ipcon-tcpip und hier z.B. die für das Linear Poti Bricklet http://www.tinkerforge.com/doc/Software/Bricklets/LinearPoti_Bricklet_TCPIP.html#linear-poti-bricklet-tcpip Wenn dir da was fehlt, was nicht verständlich oder detailliert genug ist oder sonstige Probleme damit sind dann sag Bescheid oder frag.

In C# Bindings Version 1.1.0 geben jetzt u.a. Methoden mit nur einem Ausgabewert diesen per return zurück. Die alten Versionen der Methoden mit einem out-Parmeter sind weiterhin verfügbar und als obsolete markiert. Bei mehr als einem Ausgabewerten werden weiterhin all per out-Parameter zurückgegeben. Dank an AuronX, der diese Änderung beigesteuert hat

In Java Bindings Version 1.0.6 ist die Device Klasse jetzt public und abstract.

Es gibt noch kein removeListener Funktion, aber du hast recht so etwas fehlt noch. Bis ich das eingebaut habe funktioniert der Workaround den AuronX beschreibt.

Loetkolben, wie gesagt ist das kein Fehler und die Meldung daher keine Fehlermeldung Zu der 20 Frage: $ python -c 'print str(20.00)' 20.0 Wenn du da ein spezielles Ausgabeformat brauchst dann kannst du einfach das Python Script anpassen. Da du eh schon aus print('Temperature: ' + str(temperature) + ' °C') den Text entfernt hast kannst du das Beispiel ja auch noch weiter anpassen. Immer 2 Nachkommastellen bekommst du so: print('%.2f' % temperature)

Ich werde die Meldung entfernen, den sie hat keinen Mehrwert und stiftet nur Verwirrung wie dieser Thread beweist Außerdem werden Callbacks/Antworten mit unbekannter Function ID eh schon stillschweigend ignoriert.

Du musst da nichts "adden", UID ändern und Beispiel muss funktionieren, tut es ja auch Die Meldung deutet nicht auf ein Problem oder Fehler hin, sondern nur das die IPConnection etwas unerwartetes empfangen hat und es ignoriert hat.

Die Meldung bedeutet, dass die IPConnection eine Nachricht mit Function ID 8 (das ist der Temperature.CALLBACK_TEMPERATURE) vom Stackteilnehmer 2 (das wird wohl das Temperature Bricklet sein) erhalten hat. Aber es kennt keinen Stackteilnehmer 2, daher "unknown Stack ID". Hast du den Brick Viewer auf und den Tab für das Temperature Bricklet aktiv? Dann hat der Brick Viewer den Temperature.CALLBACK_TEMPERATURE Callback für das Bricklet aktiviert und es sendet Callbacks. Wenn du nun dein Script startest dann gibt es ein kleines Zeitfenster zwischen der Erzeugung der IPConnection und dem add_device Aufruf. In dieser Zeit empfängt die IPConnection schon eingehende Nachrichten kennt aber das Temperature Bricklet noch nicht. Du kannst diese Meldung vermeiden indem du brickv oder wer auch immer den Temperature.CALLBACK_TEMPERATURE Callback aktiviert hat schliesst. Oder du kannst die Schleife in das Python Script einbauen, so dass du nicht immer die IPConnection neu erstellst. Aber eigentlich könnte ich diese Meldung auch aus allen Bindings entfernen. Callbacks/Antworten von unbekannten Devices werden eh ignoriert.