photron

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.

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.