photron

Ist korrigiert, danke für den Hinweis.

Das nenn' ich mal einen stabilen und wetterfesten Aufbau

Hab's gerade eingebaut. Qt bietet da gleich eine Option für. Ist dann in der nächsten brickv Version mit drin.

Argh, irgendwie ist in dem Stück Dokumentation der Wurm drin. Sorry. Es muss natürlich "device_identifier - uint16" lauten und ist jetzt auch korrigiert. Danke für die Hinweise.

Nein, das ist richtig. Auf TCP/IP Ebene sind uid und connected_uid des Enumerate Callbacks uint32, genauso wie die UID im Header jedes Packets auch uint32 ist. Die Bindings machen dann die Umwandlung zwischen Base58 und uint32, damit die UIDs auf Benutzerebene immer Base58 sind. Edit: Du hast recht, die Dokumentation passte nicht. Ich habe mich da an eine erste Version von Protokoll 2.0 erinnert, sorry. Dokumentation ist jetzt korrigiert.

Wenn der IPConnection.Connect() Aufruf keine Exception wirft, dann konnte eine TCP/IP Verbindung aufgebaut werden. Dass heißt, dass da etwas auf dem Port lauscht. In dem Zuge wird auch der Connected Callback aufgerufen. Höchstwahrscheinlich lauscht dann da ein brickd. Dass heißt, aber noch nicht dass da auch ein Stack angeschlossen ist. Wenn du jetzt die UID eines der Stack Teilnehmer kennst, dann kannst du einfach für diesen einen Getter aufrufen. Zum Beispiel GetStackVoltage() oder GetIdentity(). Falls keine TimeoutException geworfen wird, dann hat der Teilnehmer geantwortet und ist somit da. Falls eine TimeoutException geworfen wird dann ist da entweder kein Brick(let) mit dieser UID, oder es ist gar kein Stack angeschlossen. Falls du keine UID kennst, dann bleibt dir nur der Enumerate Callback mit Timeout. Wenn es ein "TinkerPing" gäbe würde das genau so funktionieren.

Die Libs an sich reichen zum Ausführen von brickd, aber nicht zum kompilieren. Dafür werden noch die Header Dateien benötigt, die aus *-devel Paketen kommen: sudo yum install libusb1-devel libudev-devel Außerdem fehlt dir GCC. Den kannst du mittels sudo yum groupinstall "Development Tools" installieren, dabei werden auch noch weitere nötige Pakete installiert. Jetzt sollte make alles finden und das Kompilieren funktionieren.

Dir fehlt require 'tinkerforge/bricklet_lcd_20x4' daher ist BrickletLCD20x4 unbekannt.

Neue Bindings funktionieren ohne Probleme mit alten brickd Versionen. Der alte brickd schickt die Disconnect-Probes an den Brick weiter und der Brick ignoriert sie. Da die Disconnect-Probes für USB keinen Sinn machen leitet brickd 2.0.4 sie nicht mehr weiter.

Brick Daemon 2.0.4 NSIS installer automatically installs/updates the WinUSB driver on Windows < 8 Improve callback related log messages Fix wrong log level of startup greeting on Windows Drop incoming disconnect probe requests Fix packet buffer handling in unlikely error case Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.4 NSIS Installer für Windows installiert den WinUSB Treiber auf Windows < 8 Callback-bezogene Logeinträge verbessert Falsches Log-Level für die Startup-Meldung auf Windows korrigiert Eingehende Disconnect-Probes werden verworfen Packet-Buffer-Behandlung im Fehlerfall korrigiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Bindings: C/C++ 2.0.5, C# 2.0.6, Delphi 2.0.8, Java 2.0.6, PHP 2.0.6, Python 2.0.6, Ruby 2.0.6, VB.NET 2.0.2 Enable/Disable Funktionen für die PositionReached und VelocityReached Callbacks zur Servo Brick API hinzugefügt [alle] get/set_i2c_mode (100kHz/400kHz) Funktionen zur Temperature Bricklet API hinzugefügt [alle] Standardtext Funktionen zur LCD 20x4 Bricklet API hinzugefügt [alle] Auto-Reconnect bei Socketfehler korrigiert [C# und VB.NET] Callbacks werden nach einem Disconnect nicht länger ausgeliefert [alle] Race Condition in der Callback-Behandlung korrigiert, die dazu führen konnte, dass der falsche Socket geschlossen wurde [alle, außer PHP] Socketfehler werden beim Senden nicht mehr ignoriert [alle] Spätestens alle 10 Sekunden wird ein Request gesendet, um die Erkennung von WIFI Disconnects zu verbessern [alle] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

Bindings: C/C++ 2.0.5, C# 2.0.6, Delphi 2.0.8, Java 2.0.6, PHP 2.0.6, Python 2.0.6, Ruby 2.0.6, VB.NET 2.0.2 Add enable/disable functions for PositionReached and VelocityReached callbacks to Servo Brick API [all] Add get/set_i2c_mode (100kHz/400kHz) functions to Temperature Bricklet API [all] Add default text functions to LCD 20x4 Bricklet API [all] Fix auto reconnect on socket receive error [C# and VB.NET] Don't dispatch callbacks after disconnect [all] Fix race condition in callback handling that could result in closing the wrong socket [all, except PHP] Don't ignore socket errors on send [all] Send a request at least every 10sec to improve WIFI disconnect detection [all] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby, VB.NET

Ja, das Problem ist leider, dass GDB das Programm beim RunError nicht angehalten hat. Ich habe mir auch gerade mal den Code der cthreads Unit angesehen und es hätte nichts geholfen, da an dieser nicht mehr ersichtlich ist was da zu früh aufgerufen wurde. Sorry, für den nutzlosen Vorschlag mit GDB. Ich habe gerade Lazarus auf einem Raspberry Pi (mit aktuellem Raspbian, brickd und brickv) installiert und kann das Problem nicht nachstellen. Meine project1.lpr Datei sieht so aus: program project1; {$mode objfpc}{$H+} uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this }; {$R *.res} begin Application.Initialize; Application.CreateForm(TForm1, Form1); Application.Run; end. Wenn jetzt aus irgendwelchen Gründen UseCThreads nicht definiert ist dann ist cthreads nicht die erste Unit, sondern Interfaces. Wenn das bei dir auch so aussieht, dann teste doch mal ob es hilft, die IFDEFs um cthreads zu entfernen, damit dass dann so aussieht: program project1; {$mode objfpc}{$H+} uses cthreads, Interfaces, // this includes the LCL widgetset Forms, Unit1 { you can add units after this }; [...]

Okay, du meintest also wirklich die Software Version. Ich hatte das als Hardware Version verstanden. Dann kannst du auch noch versuchen, den Aufbau auf Software Version 1.x downzugraden, um zu sehen ob das einen Unterschied macht.

Das mag sein, halte ich allerdings für unwahrscheinlich. Aber raten hilft da nicht. Daher die Frage nach einem Backtrace für den RunError.

Dann gilt es jetzt rauszubekommen, wer da cthreads zu früh benutzt. Lazarus sollte dir doch anzeigen können wo der RunError geworfen wird. Ansonsten kannst du project1 auch in gdb starten um einen Backtrace zu erhalten.

RunError 211 bedeutet, dass eine abstrakte Methode aufgerufen wurde. Wenn du project1 von der Console statt in Lazarus startest solltest du eine Fehlermeldung mit mehr Details erhalten.

Windows 8 kann den Brick automatisch als WinUSB Gerät erkennen und selbständig den passenden Treiber installieren. Das funktioniert exakt so wie z.B. bei einem USB Stick. Unter welchem Namen wird den der Brick im Geräte Manager angezeigt? Es könnte sein, dass der Brick im Bootloader ist, dann sollte ihn Windows als serielle Schnitstelle namens "GPS Camera Detect" erkennen. In dem Fall musst du ihn nur über den Brick Viewer neu flashen: http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing

Es könnte an elektrostatischer Entladung liegen, ja. So langsam gehen mir allerdings die Ideen aus. Ich versuche das ganze mal zusammenzufassen: Also, das Problem tritt nach einiger Zeit auf wenn du den Aufbau einfach vor sich hin laufen lässt. Das Problem ist, dass der Master Brick nicht mehr antwortet und erst ein Druck auf den Reset Knopf oder Trennen der Stromversorgung das Problem behebt. Es ist auch einmal vorgekommen, dass sich der Master Brick wieder von selbst bekrabbelt hat nach 15min ohne Reaktion. Ein aktiver USB Hub scheint nicht zu helfen, womit eine möglicherweise zu schwache USB Stromversorgung durch das Netbook als Ursache wahrscheinlich nicht in Betracht kommt. Dennoch solltest du wenn möglich mal mit einen anderen Rechner testen. Andererseits hat das bloße Einstecken eines USB Sticks am Netbook (oder war das am aktiven USB Hub?) das Problem zumindest einmal ausgelöst, ist aber nicht reproduzierbar. Da es wahrscheinlich nicht mit der USB Stromversorgung zusammenhängt, liegt es dann vielleicht an statischer Aufladung deinerseits die beim Einstecken zum Aufbau hin entladen wurde? Du betreibst erfolgreich einen ähnlichen Aufbau, der diese Problem nicht aufweißt. Da schaltest du auch über ein Relais eine Heizfolie? Oder tut der funktionierende Aufbau etwas anderes? Schirmung per ESD Tüte hatte keine Wirkung. Jemandem hier im Forum der große Pumpen schaltet hat eine metallene Keksdose als Schirmung geholfen. Vielleicht ist eine andere Schirmung noch mal einen Versuch wert.

Ich habe das Simple C# Example für das Analog In Bricklet genommen, um den Getter Aufruf und die Ausgabe eine while true Schleife mit 2,5sec Sleep gemacht und es über WIFI zum Stack eine Verbindung aufgebaut. Während das Programm läuft kann ich ohne Probleme über WIFI auch mit brickv zum Stack eine Verbindung auf- und abbauen ohne dass dies das C# Programm stört. Mein Stack besteht aus WIFI Extension, Master Brick und Analog In Bricklet an Port C. Will sagen ich kann dein Problem nicht reproduzieren. Kannst du mir dein Programm zeigen, vielleicht tust du doch etwas besonderes, dass das Problem hervorruft.

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.