photron

Die Bindings speichern den originale Hostnamen als String und verwenden den beim Reconnect. Wenn da ein Caching-Problem beim Auflösen existiert, wüsste ich nicht wie wir das auf der Ebene der Bindings verbessern sollten.

AuronX, deine Erklärung ist vollständig richtig so. Das ist auch in allen Bindungs so, außer PHP, weil das keine Threads hat und eh etwas abweicht. Verbindungsverlust wird an Fehlern beim Schreiben/Lesen des Sockets erkannt. Wenn Auto-Reconnect erlaubt ist (set_auto_reconnect(true)), dann versucht der Callback-Thread nach dem Ausliefern des Diconnected-Callbacks die Verbindung wieder aufzubauen. Dies tut er solange bis eines der folgenden Ereignisse eintritt: a) die Verbindung wurde wieder aufgebaut b) disconnect() wurde aufgerufen, Auto-Reconnect wird abgebrochen c) set_auto_reconnect(false) wurde aufgerufen, Auto-Reconnect wird abgebrochen Es gibt da keine zeitliche Beschränkung, und set_timeout() hat damit nichts zu tun.

Plugins: Voltage/Current Bricklet 2.0.3 Fix voltage and power reached callbacks, were send as current reached callback before Download Plugin: Voltage/Current Bricklet 2.0.3

Plugins: Voltage/Current Bricklet 2.0.3 Voltage und Power Reached Callbacks funktionieren wieder, wurden zuvor fälschlicherweise als Current Reached Callback versandt Download Plugin: Voltage/Current Bricklet 2.0.3

Für einen Stapel wird immer ein Master Brick als unterster Brick benötigt.

Generell gilt, dass du die Kommunikation aus dem Tritt bringen kannst, wenn z.B. in den Headern der Pakete falsche Daten stehen. Das Problem hatten wir ja schon Das die IP Connection "hängt" und keine Callbacks mehr ausliefert, kann daran liegen, dass der Receive Thread nicht mehr richtig funktioniert und keine Callback-Pakete mehr empfängt; oder daran, dass du den Callback Thread in einer deiner Callback-Funktionen blockierst, das gibt dein Testprogramm allerdings nicht her. Dass dc_set_velocity ohne Response-Expected E_OK sagt ist zu erwarten, da E_OK bei Settern ohne Response-Expected soviel heißt wie: ich bin die Anfrage über den Socket losgeworden, mehr nicht. Die beiden Stacktraces im ersten Post sehen normal aus. Dass das dc_disable() beidem Beenden allerdings im ipcon_send_request() ewig auf den socket_mutex wartet ist verdächtig. Wobei da Zeile 1525 nicht passt, es müsste 1523 sein, hast du da vielleicht lokale Änderungen in ip_connection.c, oder verwendest doch nicht die aktuelle Version? Interessant wäre hier ein voller Stacktrace aller Thread um zu sehen, wer da gerade auf dem socket_mutex sitzt. Das du nach dem ipcon_connect() eine sleep(1) brauchst um einen Segfault zu vermeiden ist verdächtig. Eigentlich sollte ipcon_connect() nicht auf das Starten des Receive und des Callback Thread warten müssen. Diese sind nicht an der Initialisierung globaler Datenstrukturen beteiligt. Soll heißen, selbst wenn die beiden Thread nie starten solltest du im schlimmsten Fall einfach keine Antworten auf Getter und keine Callbacks bekommen, aber keinen Segfault. Hast du dir male neben GDB Traces angesehen was Valgrind zu deinem Programm meint.

Das ist komisch. Hast du mal versucht, das Bricklet neu zu flashen?

Geany kannst du an der Stelle nicht mit Visual Studio vergleichen. Visual Studio gibt es ja in verschiedenen Varianten für verschiedene Programmiersprachen wie C++, C#, Visual Basic, etc. Für diese Sprachen bietet es dann auch vollständige Unterstützung im Sinne von Projektverwaltung, Compiler/Debugger Integration etc. Das alles bietet Geany so nicht. Geany ist in dem Sinne nur ein Editor und nicht mit einem Compiler/Debugger integriert und hat daher auch keine Einstellungen dafür. Damit unter C++ #include funktioniert musst du ja die C/C++ Bindings entweder in das gleiche Verzeichnis wie deinen Code packen oder in ein Verzeichnis in dem Visual Studio nachschaut wenn es #include auflöst. Das funktioniert in Python mit import ähnlich. Im ZIP der Python Bindings befindet sich im source Unterordner ein tinkerforge Ordner, den kannst du einfach in den gleichen Ordner wie dein Python Script packen, dann findet Python den. Oder du kannst das tinkerforge.egg installieren, dann findet Python das auch. Details gibts dazu hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#api-bindings-python Das hat im Übrigen nichts mit Geany zu tun, sondern rein mit Python. Die Python Bindings müssen sich einfach nur an einer Stelle befinden an der Python sie findet. Dann kannst du die Beispiele, die sich auch im ZIP befinden in einem Terminal ausführen. In Geany kannst du ein neues Python Script erstellen. Geany muss dazu nichts darüber wissen wo die Python Bindings sind.

Geany ist ja eher ein Editor und keine volle Entwicklungsumgebung. Die Projektverwaltung die Geany bietet ist sehr einfach gehalten. Mir ist dein Problem nicht klar. Du kannst da in Geany nichts einbinden in dem Sinne. Geany erlaubt dir nur einen Satz an irgendwelchen Dateien als ein Projekt zu definieren und es bietet einen einfachen Mechanismus um aus dem GUI heraus Dinge wie make aufzurufen. Geany ist ein guter Editor (ist mein Standardeditor), aber keine vollständige Entwicklungsumgebung für eine spezielle Programmiersprache. Um welche Programmiersprache geht es denn überhaupt?

Das habe ich gerade korrigiert, Danke für den Hinweis.

Der Verbrauch des Industrial Digital 4 In variiert nur minimalst abhängig von der Beschaltung der Eingänge. Das definiere ich jetzt mal als festen Verbrauch Beim Industrial Digital 4 Out wird bei High eine LED im Optokoppler eingeschaltet, das verbraucht dann 2mA pro Ausgang auf High. Das habe ich jetzt in der Doku und im Shop korrigiert. Danke für die Nachfrage.

Ertappt Ich hatte beim Quad Relay nicht im geschalteten Zustand gemessen. Jetzt ist die Angabe wie beim Dual Relay: Pro Relais im geschalteten Zustand. Macht 2mA pro geschaltetem Relais.

Ist jetzt für alle Bricks, Bricklets und Extensions dokumentiert.

Nein, davon kannst du nicht ausgehen. Der Eigenverbrauch liegt deutlich unter 25mA wenn nichts angegeben ist. Ich setze mir mal auf die TODO Liste den Eigenverbrauch für alle Bricklets zu messen bei denen das noch nicht angegeben ist.

Am einfachsten packst du die benötigten Dateien der Bindings in den gleichen Ordner wie den Quelltext deines Programms und fügst sie dem Dev-C++ Projekt hinzu. Das sollte schon reichen. Im Fall der Wetterstation sind das ip_connection.c ip_connection.h bricklet_lcd_20x4.c bricklet_lcd_20x4.h bricklet_ambient_light.c bricklet_ambient_light.h bricklet_barometer.c bricklet_barometer.h bricklet_humidity.c bricklet_humidity.h Falls du dein Programm in C++ statt C schreibst muss du die .c Dateien nach .cpp umbenennen. Ich hab jetzt auch mal hier die Dokumentation dafür erweitert: http://www.tinkerforge.com/de/doc/Software/API_Bindings_C.html#orwell-dev-c

Richtig, das ist exakt das Problem. Danke für's Debuggen und sorry, dass mir das nicht aufgefallen ist. In C/C++ 2.0.8 Bindings ist das jetzt korrigiert.

Bindings: C/C++ 2.0.8 Avoid potential infinite loop in receive thread Handle incoming data correctly if multiple packets are received at once Download: C/C++

Bindings: C/C++ 2.0.8 Möglichkeit einer nicht abbrechenden while Schleife im Receive-Thread unterbunden Eingehende Daten werden korrekt behandelt wenn mehrere Packete auf einmal empfangen werden Download: C/C++

Ich hab die Dokumentation aktualisiert. Mit Antenne steigt der Verbrauch um ca. 10mA.

Wie sieht die Fehlermeldung aus, die du bekommst, wenn der Compiler "spinnt"? Versucht du das in der Arduino IDE zu kompilieren? Das wird nicht funktionieren. Du brauchst sowas wie Microsoft Visual Studio Express oder Qt Creator oder Dev-C++. Das hat nichts mit Windows XP zu tun, das ist nicht dein Problem. Da die C Bindings auch für ObjC funktionieren, wird es von uns zumindest in nächster Zeit keine speziellen ObjC Bindings geben.

Wo fügst du denn die Bindings ein? Welche Fehlermeldungen bekommst du denn? Was für Plugins meinst du? Die C/C++ Bindings sind mit dem GCC/G++ Compiler (auch MinGW) und dem Microsoft Visual Studio Compiler getestet, sollten aber auch mit anderen C/C++ Compilern funktionieren.

Das bedeutet, dass ein zu brickd verbundenes Programm (brickv, oder dein eigens Steuerprogramm) die TCP/IP Verbindung aktiv beendet hat und dies von der brickd Seite nicht erwartet war, da noch Aktionen ausstanden. Das kann z.B. sein, dass noch Daten zu lesen waren oder ähnliches. Das kann mit deinem Relais Problem zusammenhängen, muss es aber nicht. Es kann auch einfach nur auf ungünstiges Verhalten in deinem Programm hindeuten. Schwer zu sagen nur aus der Fehlermeldung heraus

Das ist komisch. Ich habe mir gerade die Änderungen zwischen 2.0.5 und 2.0.7 angesehen und da ist nichts dabei was diese Verhalten auf Anhieb erklärt. Okay zum Backtrace: der Receive Thread (Thread 2 in gdb) scheint im table_get() zu stehen. Das ist komisch. Auch das der table_get() Aufruf für UID 0ist, ist komisch, da UID keine gültige UID für ein Brick oder Bricklet ist. Weiterhin ist im ipcon_receive_loop() Aufruf pending_length = 34, der erste Header in pending_data ist aber voller Nullen. Will sagen, da ist was sehr faul. Da der Header voller Nullen ist ist length in Zeile 1302 auch 0 und damit bleibt pending_data auf 34 und die while (true) Schleife in Zeile 1296 bricht nicht ab und der Thread endet nicht. Der Receive Thread steht also nicht in table_get(), sondern du hast den Thread nur gerade zufällig da angehalten. Das Problem ist also, dass im pending_data Buffer falsche Daten stehen (lauter Nullen). Die Frage ist jetzt wie die dahin gekommen sind: Hat brickd die wirklich geschickt? Du könntest mit Version 2.0.7 nach dem socket_receive in Zeile 1272 einmal die Werte von length, pending_length und den Inhalt von pending_data per printf oder Ähnlichem ausgeben, um zu sehen ob da die Nullen wegkommen. Als Änderung für die IP Connection werde ich erstmal die while (true) Schleife in Zeile 196 durch eine while (ipcon->receive_flag) Schleife ändern, dann sollte das pthread_join() nicht mehr vergeblich warten. Das eigentliche Problem, dass im pending_data Buffer bei dir 34 Nullen stehen ist damit allerdings nicht behoben oder erklärt.

pthread_join() blockt weil es darauf wartet, dass sich der Receive Thread beendet, was aber nicht zu passieren scheint. Ich denke, dass der in recv() steht und der shutdown() Aufruf den recv() Aufruf nicht abgebrochen hat. Kannst du das Problem einfach reproduzieren? Mich interessiert ein gdb Backtrace für alle Threads: thread apply all backtrace full Um zu sehen wo der Receive Thread wirklich steht.

Danke für den Hinweise. Link ist korrigiert.