photron

bauerb, meinst du a) dass du von der IP Connection in deinem C# Programm wirklich einen Disconnected Callback erhältst, oder b) nutzt dein Programm den Voltage Callback des Analog In Bricklets und sobald du in brickv die Verbindung schließt kommen in deinem Programm keine Callbacks mehr an? Fall es b) ist das erwartet, da der Brick Viewer auch den Callback des Analog In Bricklets verwendet und konfiguriert. Damit kann brickv deinem Programm in die Quere kommen, weil er beim Beenden der Verbindung die Callbacks wieder deaktiviert.

Relais Es ist also ohne Heizfolie 3 Tage gelaufen. Daraus mag man jetzt ableiten, dass da ein Zusammenhang ist. Bei 6A Strom hast du da sicherlich Funkenbildung im Relais, welche den Master Brick stören könnte. Außerdem ist das durchaus eine Belastung für die Kontakte des Relais, wenn du es bei dieser Last alle 3 Sekunden schaltest. Gibt es einen speziellen Grund warum du die Heizfolie statt mit 12V nur mit 9V betreibst? Bei höherer Spannung könnte der Strom bei gleicher Leistung verringert werden. Ähnlich steht es mit der Verschaltung der Heizdecken. Wenn du sie in Reihe statt parallel schalten würdest, könntest du die Spannung verdoppeln und den Strom halbieren. Noch mal zu den 6A: Laut Datenblatt des PeakTech 1885 kann das nur maximal 5A. Wie kommst du da auf 6A? USB Interessant ist die USB-Stick Sache. Ist das reproduzierbar? Das deute auf ein Problem mit der USB Versorgung des Netbooks hin. Dazu würde auch passen dass das Relais im Peak etwas mehr Strom braucht wenn es belastet geschaltet wird. Dadurch funktioniert es 3 Tage ohne Heizfolie. Mit Last kommt es dann aber eher über das Limit des Netbooks. Dagegen spricht, dass dein Test mit einem extern versorgten USB Hub nichts gebracht hat. War die Versorgung des Hubs vielleicht zu schwach? Du sagtest, du hättest einen sehr ähnlichen Aufbau an einem anderen Rechner laufen. Besteht die Chance den problematischen Aufbau mit diesem Rechner zu testen, um herauszufinden ob das Netbook das Problem ist?

Ich habe da eine Vermutung. Kannst du folgendes testen? In /usr/share/brickv/plugin_system/plugins/imu/imu_gl_widget.py die Zeile mit self.initializeGL() auskommentieren oder entfernen. Das ist ca. in Zeile 59. Dieser Aufruf ist nicht notwendig, sollte aber eigentlich kein Problem machen. Es kann aber sein, dass in deinem Fall zu dem Zeitpunkt kein OpenGL Kontext aktiv ist und der glClearColor Aufruf in initializeGL das nicht verträgt.

FabianB, das ist nicht die aktuelle Version des Start-Stop Skripts. ufechner, das aktuelle Start-Stop Skript ist auch im git: http://github.com/Tinkerforge/brickd/blob/master/src/build_data/linux/etc/init.d/brickd Das Makefile hat im Moment kein install Target, mit dem man brickd richtig installieren könnte. Ich setzt das mal auf die TODO Liste.

Okay, das ist komisch. Wenn brickd Requests in die Write Queue packt, dann sind alle 5 Write Transfers für den Brick unterwegs. Das ist an sich schon nicht normal. Dass dann aber nach über 12min (256 Requests in der Queue + N verworfene Requests bei einem Request alle 3 Sekunden) wieder ein Write Transfer zurück kommt und wieder abgeschickt werden kann ist komisch. Wurde denn dann die Queue schnell geleert, oder ging nur der eine Transfer raus und der dann nicht direkt wieder zurück? Was auch noch komisch ist, ist das hier eine Getter Response des Temperatur Bricklets anzukommen scheint, wobei in den 6sec Log davor kein Request dafür rausgeht. 2013-03-12 14:07:49.714391 <D> <transfer.c:72> Read transfer 0x21d19c0 returned successfully from Master Brick [6krz2t] 2013-03-12 14:07:49.714439 <D> <brick.c:85> Got response (U: 42220, L: 10, F: 1, S: 3, E: 0) from Master Brick [6krz2t] 2013-03-12 14:07:49.714502 <D> <network.c:260> Dispatching response (U: 42220, L: 10, F: 1, S: 3, E: 0) to 2 client(s) 2013-03-12 14:07:49.714552 <W> <network.c:278> Broadcasting response because no client has a matching pending request 2013-03-12 14:07:49.714704 <D> <client.c:232> Forced to sent response to client (socket: 16, peer: 127.0.0.1) 2013-03-12 14:07:49.714833 <D> <client.c:232> Forced to sent response to client (socket: 15, peer: 127.0.0.1) Danach gehen Enumerate Callbacks vom ganzen Stack (1 Brick, 2 Bricklets) ein. Leider kann ich aus dem Log nicht ersehen ob das vom Brick oder durch dein Programm/brickv getriggert wurde. Das ist alles sehr suspekt muss ich sagen. Es sieht fast so aus als ob der Brick sich da für über 12min einfach entschieden hätte nichts zu tun um dann wieder zu funktionieren Weitere Fragen Hast du mal getestet ob das Problem auch auftritt, wenn du die Heizdecke nicht am Relais hast? Kannst du mir deinen Hardwareaufbau (inklusive Kabellängen) exakt beschreiben und dein Python Script zukommen lassen, damit ich das hier mal nachstellen kann? Der andere funktionierende Aufbau unterscheidete sich darin, dass er einen Maste Brick Hardware Version 1.x verwendet, ein Analog In Bricklet statt eines Temperature Bricklets und dass er an nicht an einem Netbook, sondern was hängt? Ansonsten tut er aber das gleiche und regelt eine Heizdecke?

FlyingDoc, warum schreibst du statt UID = (char *)malloc((strlen(device_uid)) * sizeof(char)); size_t n = (strlen(device_uid)) * sizeof(char); if(UID) { _strset( UID, 0 ); strncpy_s(UID,strlen(device_uid), device_uid, strlen(device_uid)-1); nicht einfach UID = strdup(device_uid); if (UID) {

andreas301, du musst beim Aufruf von temperature_register_callback als 4. Parameter statt NULL &dr übergeben.

Okay, es geht also in OpenGL kaputt. Funktionieren den andere OpenGL Programme, wie z.B. das OpenGL Testprogramm glxgears?

Das Problem ist mit Delphi Bindings Version 2.0.7 korrigiert.

Bindings: Delphi 2.0.7 Fix IP address lookup on Linux if hostname is already given in dotted decimal format Download: Delphi

Bindings: Delphi 2.0.7 IP Adressen Lookup auf Linux korrigiert, im Falle, dass der Hostname schon in X.Y.Z.W Notation angegeben ist Download: Delphi

berndlu, das ist wirklich ein Bug in den Delphi Bindings, der nur FPC auf Linux betrifft. Wenn du den Hostname als 192.168.1.150 angibst versucht die IPConnection das noch mal zu einer IP Adresse aufzulösen, scheitert aber. Es wird im Laufe des Tages eine korrigierte Version geben.

Link ist korrigiert.

Ich denke wir können Ruby Gem auf rubygems.org hochladen. Ich setze mir mal auf die TODO Liste anzuschauen wie wir das im Release Prozess der Bindings mit automatisieren können.

Brick Viewer 2.0.4 Ignore enumerate callbacks that arrived after a disconnect Fix Chibi and RS485 configuration handling Disable instead of hide WIFI hostname edit box, if Master Brick firmware doesn't support it Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.0.4 Enumerate Callbacks die nach einem Disconnect ankommen werden ignoriert Problem in Chibi und RS485 Konfigurationsdialog korrigiert WIFI Hostname Eingabefeld wird deaktiviert statt ausgeblendet, wenn Master Brick Firmware dies nicht unterstützt Downloads: Windows, Linux, Mac OS X

We're using Qt for the UI. Qt doesn't support multi line text on tab handles.

It could retry but that wouldn't help much in general. In your case a spontaneous timeout hits is_wifi_present(). But a spontaneous timeout might hit any other function call as well. We'd have to add retry handling to all API function calls. That's quite a lot of work. I'll note it down as a future enhancement possibility.

Ist jetzt auch dokumentiert. Jeder Brick und Bricklet hat jetzt in der API Dokumentation einen Abschnitt über Konstanten.

Log Also, das Log nach dem brickd Neustart zeigt, dass brickd den Master Brick korrekt findet und initialisiert. 4sec später nimmt er die eingehende TCP Verbindung an. Dein Programm ruft einen Getter eines Bricklets auf. Brickd sendet die Anfrage korrekt an den Master Brick weiter. Der Write Transfer kommt ohne Fehler zurück, was für brickd bedeutet, dass die Anfrage korrekt an den Master Brick ausgeliefert wurde. 2,5sec später ruft dein Programm einen Setter auf einem anderen Bricklet auf. Auch diese Anfrage geht korrekt an den Master Brick raus. Es ist noch keine Antwort auf den ersten Getter Aufruf angekommen und da mittlerweile 2,5sec vergangen sind wird jetzt in deinem Programm eine TimeoutException geworfen. Ich nehme an du behandelst diese nicht und dein Programm wird abgebrochen. Daher wird jetzt die TCP Verbindung zum brickd getrennt. Damit endet das Log. Bezüglich "Broadcasting request because no Brick knows the UID", das ist okay. Brickd arbeitet wie ein Switch und lernt hinter welchem USB Gerät sich welche UIDs verbergen. Der Eintrag besagt einfach, das brickd noch nicht weiss hinter welchem USB Gerät sich die UID für diese Anfrage befindet und daher wird die Anfrage an alle geschickt. Verständlicher wäre wahrscheinlich "Broadcasting request because UID is currently unknown" als Logeintrag. Von brickd Seite ist das alles vollkommen okay, es ist kein Neustart von brickd notwendig. Was da passiert ist, dass auf den Getter Aufruf keine Antwort innerhalb des Timeouts kommt. Dies scheint kein vereinzelte Timeout zu sein, denn sonst müsste dein Programm weiter funktionieren, wenn du des nach dem Abbruch neustartest. Es scheint als hätte der Master Brick aufgehört zu antworten. Das ist nicht normal. USB Da dmesg nichts besonderes zeigt ist es zumindest kein USB Problem, dass der Kernel erkennen könnte. Auch im brickd Log funktioniert USB normal. Der aktive USB Hub ist einen Versuch wert. Das Dual Relay Bricklet braucht zum Schalten kurzzeitig mehr Strom (60mA). Möglicherweise geben das die USB Buchsen der Netbooks nicht her. Last Was ist das für ein Gerät das du da schaltest bei 12V/6A? Ein Motor, eine Lampe, etc? Ich frage, weil es im Zusammenhang mit dem Dual Relay in seltenen Fällen EMV Probleme gab. Das also der Master Brick durch das Schalten gestört wird. Es kann auch sein, dass unabhängig davon etwas in der Umgebung des Bricks ist was diesen gestört hat. Deswegen auch die Frage nach der Länge der Bricklet Kabel. Lange Kabel wirken als Antennen und fangen Störungen ein. Als weitere Möglichkeit, die du neben dem aktiven USB Hub noch testen kannst ist den Master Brick zu schirmen, z.B. in einer Metalbox, oder auch einfach mit der ESD Tüte in der er verpackt war.

Deine per AddHandler registrierte Funktion wird von einem Thread der IP Connection aufgerufen. Aus diesem Thread kannst/darfst du nicht mit dem UI interagieren. Die Lösung mittels Delegate und Invoke() wird z.B. hier beschrieben: http://tech.xster.net/tips/invoke-ui-changes-across-threads-on-vb-net/

I added "... permanently on the WIFI Extension" to the quoted sentence.

Die Dokumentation dieser beiden Callbacks waren nicht eindeutig. Das habe ich jetzt verbessert.

Log Für ein Log auf Debug Level ist das noch kurz. In dem Log sehe ich zwei Aufrufe der gleichen Setter Funktion (könnte set_state des Dual Relay sein). Dann wird die Socket Verbindung der IP Connection geschlossen. Nichts auffälliges, alles normal. Das zweite Log ist auch normal, nichts auffälliges. Brick Daemon startet seine Subsysteme, findet den Master Brick, initialisiert ihn und wartet dann darauf, dass etwas passiert. Das zweite Log zeigt, dass der Master Brick zumindest USB mässig noch funktioniert, zumindest soweit das er für Linux heile aussieht. Interessant wäre jetzt wie ein Setter Aufruf im Log aussähe, nachdem der Brick nicht mehr reagiert. Ein normaler Aufruf sähe so aus: 2013-03-01 12:46:50.362571 <D> <client.c:108> Got request (U: 36700, L: 10, F: 1, S: 11, R: 0) from client (socket: 16, peer: 127.0.0.1) 2013-03-01 12:46:50.362644 <D> <usb.c:332> Dispatching request (U: 36700, L: 10, F: 1, S: 11, R: 0) to 1 Brick(s) 2013-03-01 12:46:50.362743 <D> <transfer.c:232> Submitted write transfer 0x20aa788 for 10 bytes to Master Brick [6krz2t] 2013-03-01 12:46:50.362804 <D> <brick.c:503> Sent request to Master Brick [6krz2t] 2013-03-01 12:46:50.362861 <D> <event_posix.c:238> Handled all ready event sources 2013-03-01 12:46:50.362923 <D> <event_posix.c:177> Starting to poll on 10 event source(s) 2013-03-01 12:46:50.367796 <D> <event_posix.c:197> Poll returned 1 event source(s) as ready 2013-03-01 12:46:50.367906 <D> <event_posix.c:223> Handling USB event source (handle: 12, received events: 4) at index 7 2013-03-01 12:46:50.368013 <D> <transfer.c:72> Write transfer 0x20aa710 returned successfully from Master Brick [6krz2t] [*]Der Setter Aufruf geht bei brickd ein (Got request from client). [*]Wird an den Master Brick geschickt (Submitted write transfer to Master Brick) [*]Der Write Transfer kommt erfolgreich zurück (Write transfer returned successfully from Master Brick) Mich würde interessieren ob im 'abgestürzten' Zustand der Write Transfer in diesem Fall auch ohne Fehler zurück kommt. USB Kabel Die Frage nach dem Kabel, weil wir schon mal Probleme mit USB Kabeln ohne Ferrite Bead (der "Klumpen" hinter dem Mini-USB Stecker) hatten. dmesg In dmesg sollte das so aussehen [229718.296121] usb 6-3: new full speed USB device number 64 using ohci_hcd Linux findet ein neues USB Gerät (new full speed USB device). [229718.936149] usb 6-3: reset full speed USB device number 64 using ohci_hcd Kurz darauf wird brickd darüber informiert und führt einen Reset durch um das Gerät in einen definierten Zustand zu bringen (reset full speed USB device). [230529.492792] usb 6-3: USB disconnect, device number 64 Und hier wurde das USB Gerät wieder abgezogen. Dual Relay Bricklet Wie häufig schaltest du das und was hängt da als geschalteten Last dran? Wie lang sind die Bricklet Kabel die du verwendest?

Diese Defines gibt es schon, es fehlt aber wohl noch deren Dokumentation. Zum Beispiel #define AMBIENT_LIGHT_DEVICE_IDENTIFIER 21 in bricklet_ambient_light.h.