photron

Callbacks werden von einem eigenen Callback Thread der IP Connection ausgeführt. Typischerweise ist es in GUI Frameworks aber so, dass man nur vom Haupt Thread mit dem GUI interagieren darf. Dass heißt du kannst nicht einfach aus Callback heraus mit dem GUI interagieren. Die Probleme die du da siehst kommen daher, dass du es doch tust. Dass es auf 32bit funktioniert halte ich für Zufall. Du musst also etwas zwischen den Callback Thread und dein GUI setzen, dass sich um korrekte Kommunikation zwischen den beiden kümmert. Google fördert für wxWidgets und Python das hier zu tage: http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/ Dort werden wx.CallAfter und das Publish-Subscribe Pattern verwendet um von einem nicht-GUI Thread mit dem GUI zu kommunizieren.

Bindings: C/C++ 1.0.17 Add support for big endian systems Download: C/C++

Bindings: C/C++ 1.0.17 Support für Big Endian Systeme hinzugefügt Download: C/C++

So, die Änderungen sind jetzt auch in C/C++ Bindings 1.0.17.

Hört sich an als ob du es nicht in der richtigen Reihenfolge machst. Einmal genau Schritt für Schritt: - Master ist noch nicht am Rechner angeschlossen - brickv läuft und Connect Knopf wurde geklickt (dies verbindet brickv mit brickd, der Connect Knopf hat nichts mit der Verbindung zum Master direkt zu tun) - Bricklet an Master anschliessen (Master ist immer noch nicht per USB an Rechner angeschlossen) - jetzt erst den Master mit den Bricklets dran per USB anschliessen - der Master und die Bricklets tauchen nach einem Moment in brickv auf Die Farbe der Brickletkabel macht für die Funktion keinen Unterschied.

Wie schliesst du die Bricklets denn an? Du musst zuerst die Bricklets an den Master anschliessen und dann erst den Master an USB. Dass das schwarze Kabel am Distance IR ist definitiv nicht normal

Das kommt davon wenn man's nicht testet Ich hatte einige Stellen übersehen. Hier jetzt Version 2, da sollte ich jetzt alles erwischt haben. tinkerforge_c_bindings_1_0_16_endian_2.zip

Das ist das nicht-GUI Thread Problem das ich meinte. Du kannst mit dem GUI nicht aus einem nicht-GUI Thread interagieren. Du brauchst einen Mechanismus mit dem du vom Callback Thread sauber mit dem GUI Thread interagieren kann. In Qt kann man Signal/Slot dafür benutzen, GTK wird da auch eine Lösung für haben.

Du meinst einzelne Bricklets oder Bricks am Stack an- und abstecken, also nicht USB? Es gibt kein Hotplug im Stack. Enumerate ist nur für USB an- und abstecken.

Exakt das ist die Aufgabe des Enumerate Callbacks. Nehmen wir mal dein GUI aus der Gleichung raus. Der Preview liegt eine Example.pas bei die die Verwendung des Enumerate Callbacks demonstriert. Teste doch mal bitte diese Programm. Es sollte dich über das an- und abstecken von Bricks an USB informieren.

Du sagtest du reagierst in deinem Programm dynamisch auf ab- und anstecken von Bricks an USB mittels des Enumerate Callback. Im Falle des Absteckens kommt ein Enumerate Callback mit isNew = false. Ich rate jetzt ins Blaue und sage, dass du im Callback dann die GUI Elemente für diesen Brick wieder entfernst. Oder vielleicht es auch nur aus deinem Listenfenster entfernst. Der Backtrace den glibc da ausgibt besagt, dass dein Programm gtk_widget_queue_draw aufruft. Dieser Aufruf führt im Endeffekt zu einem "double free or corruption". Typische Ursache für so etwas ist, dass du eine GTK Funktion auf einen ungültiges Pointer aufgerufen hast, oder dass GTK es dier hier übel nimmst dass du aus einem nicht-GUI Thread (dem Callback Thread) mit dem GUI interagierst.

Hier C/C++ Bindings die jetzt Big Endian richtig behandeln sollten. tinkerforge_c_bindings_1_0_16_endian.zip

Wenn brickd gudev nicht importen kann dann steht "Could not import gudev. Disabling USB hotplug" im Log als Warning. Du scheinst aber laut Log python-gudev zu haben, denn im Log steht ganz am Ende "Removed USB device". Dies wird ausgegeben wenn brickd von udev gesagt bekommt, dass ein USB Device entfernt wurde. Sieht so aus, als würde udev also grundsätzlich funktionieren, aber es brickd nicht darüber informieren wenn ein USB Device dazugekommen ist. Fraglich ist jetzt warum das passiert. Ich würde die Ursache auf udevs Seite sehen.

Wie und welche Verbinding trennst du und wie sieht der Fehler bzw die Meldung aus?

Ich habe jetzt in den aktuellen Version aller Bindings sichergestellt, dass der Callback Thread beendet ist bevor der Receive Thread beendet wird. Damit kann das beschriebene Problem nicht mehr auftreten.

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