photron

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.

Das Brick Daemon Log ist unter /var/log/brickd.log zu finden. Schau mal was da drin steht. Dann kannst du noch per dmesg schauen was der Kernel über USB Geräte zu sagen hat. Wenn erst USB ab- und anstecken hilft, hängt es vielleicht mit USB zusammen. Ist der Brick direkt per USB an den PC angeschlossen, oder ist da noch ein Hub dazwischen? Was für ein USB Kabel verwendest du? Gibt es ein Muster wann der Brick verschwindet? Fällt es z.B. mit dem Schalten des Dual Relay Bricklets zusammen?

Für das 0-20mA Bricklet haben wir hier einen Prototypen liegen und für ein Industrial Analog Out Bricklet wird noch über mögliche Realisierungen nachgedacht. Das 0-20mA Bricklet steht jetzt auch in der Timeline. Potentiell kommt es nach der Ethernet Extension. Wann genau können wir noch nicht sagen. Für ein Industrial Analog Out Bricklet können wir dir keine weitere Angaben machen.

Ja, ein Bug in der Firmware. Ist in Version 2.0.1 korrigiert.

Firmwares: IO-16 Bricklet 2.0.1 Add missing invocation for set_selected_values function Download: IO-16 Bricklet

Firmwares: IO-16 Bricklet 2.0.1 Fehlenden Aufruf für set_selected_values hinzugefügt Download: IO-16 Bricklet

This Connect/Disconnect button enable/disable logic is already present since Brick Viewer 2.0.1. But it doesn't seem to help in your case.

From your other brickv screenshot I can see that you have Master Brick firmware 2.0.4. This feature is new in firmware 2.0.5 and brickv hides this option for older firmwares.

I thinks what's happening here is that brickv calls is_wifi_present() on the Master Brick and this calls gets a timeout (see the timeout counter shows 1). This makes brickv not show the WIFI configuration UI.

That's interesting. I didn't expect that DHCP would be the cause for this timeouts. Good to know!

Dann hast du einen Master Brick Hardware Version 2.0. Der hat dummerweise eine Änderung drauf, die dafür sorgt, dass der Brick nicht ordentlich in den Bootloader wechselt, wenn eine Master Extension wie WIFI oder RS485 im Stack ist. Das FAQ hat jetzt auch einen Abschnitt über Ursachen dafür, dass ein Brick nicht ordentlich als serielle Schnittstelle auftaucht.

Hier sind also beide per WIFI am AP angebunden? Und hier ist der Rechner per LAN statt WIFI angebunden und der Stack noch wie zuvor? Das macht irgendwie keinen Sinn, oder? Deute für mich darauf hin, dass das Problem auf der LAN Seite liegt, oder nicht? Ist der Durchsatz im LAN so schlecht, dass eine Nachricht vom Rechner zum Stack und zurück einfach länger also 2,5sec braucht?

Does this log tell that it works in general, but that there are some spontaneous TimeoutExceptions in between? I assume you're still calling getDistance() every 500ms. This might be due to WIFI reconnects. You could add the IPConnection ConnectedListener and DisconnectedListener to be able to log automatic reconnects of the IP Connection. Did you have a look at the logs of you WIFI access point? Are there any reconnects from the WIFI Extension at the time the TimeoutException occur? Maybe there was a reconnect just in the middle of a getter call. You could also log the time at which a TimeoutException occurs. For example, are the first two TimeoutExceptions from two getDistance() calls in a row, or are the minutes apart?

Ist seit Java Bindings 2.0.4 verbessert. Im gleichen Zuge habe ich auch den Response Expected Code der anderen Bindings überarbeitet.