photron

JoergK, kann ich hier so nicht reproduzieren. Funktioniert hier im Test wie es soll. Welche Master Brick Firmware Version verwendest du? Wie verhält sich die grüne LED auf der WIFI Extension? Sie sollte während des Verbindingsaufbaus blinken, und wenn die Verbindung steht dauerhaft leuchten.

Das kann ein Wärmeproblem sein. Update mal den Master Brick auf die aktuelle Firmware 2.2.2.

Okay auf den ersten Blick sehe ich das kein direktes Problem im Code. Ich bleibe bei meiner Vermutung, dass du den Interrupt in deinem Programm nicht richtig einstellst. In deinem ersten Post sprachst du von Pin 1. Meinst du damit den Pin der auf dem IO-4 Platine mit einer "1" gekennzeichnet ist? Wenn ja, dann aktiviert io4.SetInterrupt(1 << 0) nicht den Interrupt für diesen Pin, sondern für Pin 0, der auf der IO-4 Platine mit einer "0" gekennzeichnet ist. Für Pin 1 muss das so aussehen: io4.SetInterrupt(1 << 1) Dass es in deinen Tests dann doch funktioniert, wenn du in brickv auf den IO-4 Tab wechselst liegt dann daran, dass brickv in diesem Fall die Interrupts für alle Pins anmacht, also auch für Pin 1.

Der Vorschlag das Bricklet neu zu flashen ist ein Schuss ins Blaue, weil mit keine gute anderen Erklärung einfällt. Der GetInterrupt() Aufruf ist auch mehr ein Schuss ins Blaue. Dadurch wird das Problem nicht behoben werden. Interessant wäre aber, ob sich der Wert den du SetInterrupt() übergibst sich von dem unterscheidet, den dir GetInterrupt() zurück gibt. Die beiden sollten im Normalfall gleich sein. Wenn du in brickv den Tab des Bricklet anwählst werden die Interrupts für alle Pins aktiviert. Ist dein Problem vielleicht, dass dein Programm die Interrupts nicht richtig einstellt? Also SetInterrupt mit einem flaschen Wert aufruft und dann auf dem Pin auf dem du den Interrupt benutzen willst, der Interrupt gar nicht an ist? In brickv dann den Tab anzuwählen fixt das Problem, weil brickv immer die Interrupts für alle Pins anmacht. Teste mal in deinem Programm SetInterrupt(255) aufzurufen. Ich würde fast erwarten, dass das dein Problem löst.

Teste mal bitte diese kleine Script, es sollte "MSG_NOSIGNAL does NOT exist" ausgeben und sonst keine Fehler melden: use strict; use warnings; use Socket qw(MSG_NOSIGNAL); if (defined(&{"MSG_NOSIGNAL"})) { print "MSG_NOSIGNAL does exist\n"; } else { print "MSG_NOSIGNAL does NOT exist\n"; }

Interessant! MSG_NOSIGNAL macht also ein Problem. Die andere Meldung kommt daher, dass dein Thread::Queue Module nicht neu genug ist. Du brauchst mindestens Version 3.02. Das solltest du über CPAN updaten können: sudo cpan Thread::Queue

Komische Sache! Ruf doch mal nach dem SetInterrupt() in deinem Programm GetInterrupt() auf, um zu überprüfen ob der Interrupt auch wirklich aktiv ist. Hast du mal versucht das IO-4 Bricklet neu zu flashen?

Hrm, in Tinkerforge/IPConnection.pm stehen an drei Stellen Methodenaufruf mit MSG_NOSIGNAL als letzten Parameter. Ändere mal bitte alle drei ab indem du diesen Parameter entfernst und teste dann nochmal. Hier ein Beispiel: Vorher: $rc = $self->_get_local_socket()->send($packet, MSG_NOSIGNAL); Nachher: $rc = $self->_get_local_socket()->send($packet);

Steht auf jeder Seite der JavaScript Dokumentation, Zum Beispiel hier: http://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLight_Bricklet_JavaScript.html#api

Ich habe jetzt auch die Dokumentation der get_api_version() Funktion erweitert, um sie besser zu erklären.

setup.py und easy_install ist entweder oder. Die nächste Release der Bindings wird das tinkerforge.egg nicht mehr beinhalten, da diese Format mittlerweile deprecated ist und auch nicht gut funktioniert, wie du ja selbst siehst. Es wird in Zukunft nur noch "python setup.py install" und "pip install tinkerforge" geben, als Installationsoptionen. Wobei das ein entweder/oder Auswahl ist. Du muss nicht beides machen. Das geht aus der Dokumentation nicht wirklich gut hervor. Deswegen überarbeite ich die Installationsanleitungen aller Bindings auch gerade. Wenn "python setup.py install" für dich funktioniert, dann bleib dabei. Wenn du das nochmal ausführst sollte aus auch die kaputte easy_install Installation wieder retten können.

Da beide Aufrufe auf verschiedene Pins beziehen kommen sie sich nicht in die Quere. Der 2. Aufruf ändert nicht das Verhalten des schon laufenden Monoflops auf einem anderen Pin. Dein 1. Monoflop auf Pin 0 endet also nach 1,5s, wie vorgegeben.

Dann hast du wahrscheinlich pip nicht installiert, das nicht unbedingt standardmäßig bei Python dabei. Es lässt sich aber leicht nachinstallieren, siehe: https://pip.pypa.io/en/latest/installing.html

Die Bindings bieten keine Möglichkeit aus Python heraus zu bestimmen welche Release-Version es ist. Die Release-Version steht aber am Anfang der Brick und Bricklet Python Dateien in einem Kommentar. Wenn du die Bindings mit über pip installiert hast, dann kann dir pip sagen welchen Release-Version installiert ist. Bleibt die Rückfrage: Warum ist diese Information überhaupt interessant?

Loetkolben, das ist nicht die Protokoll-Version. Die kannst du nirgendwo direkt abfragen. wehnerc, das ist nicht die Release-Version der API Bindings. Die Bindings haben keine Funktion ihre Release-Version auszugeben. get_api_version() gibt die API Definitions-Version aus, die die gerade verwendeten API Bindings implementieren. Diese Versionsnummer ist recht nutzlos und die Funktion ist nur aus Gründen der Kompatibilität mit älteren Programmen noch da. Wir hätten sie beim Übergang von Protokoll-Version 1.0 auf 2.0 entfernen sollen, haben die Gelegenheit aber verpasst. Aus der API Definitions-Version kann man die Protokoll-Version ableiten, aber das war nicht deren Zweck. <Nachtrag> Die Protokoll-Version kann man natürlich auch aus der Release-Version der API Bindings und der Firmware ableiten. </Nachtrag> Hier gibt's also nichts zu sehen, bitte weitergehen

Nice cardboard construction 1) The black connector on the Stepper Brick will only supply the connected motor. There is no 5V regulator on the Brick to create 5V from the motor supply. You can use a Step-Down Power Supply and supply its black connector with up to 27V. The Step-Down Power Supply has a 5V regulator and will create 5V to supply the stack. It'll also forward the voltage you connected to its black connector to the Stepper Brick motor supply. So, if you want to supply the stack with 5V and the stepper motor from the same source then you need a Step-Down Power Supply at the bottom of the stack and feed its black connector. Without a Step-Down Power Supply you need to provide the 5V and the motor supply separately. 2) Sorry no clue, I'm going to leave this one for someone else 3) There should be no problem with calling enable()/disable() from a callback. Maybe you could show this portion of the code, so we can see how you're doing this?

Ahhhhh, jetzt weiß ich was los ist. Das ist ein Problem, dass im git schon behoben habe. Allerdings habe ich die Folgen diese Problems wohl nicht richtig beurteilt, sonst gäbe es schon brickd 2.1.1 in der es behoben wäre, sorry. Hier die Schritte den Patch dafür zu testen: cd brickd-2.1.0/src/brickd sudo apt-get install patch wget https://github.com/Tinkerforge/brickd/commit/442321f6d6619c0ff80770776f108d50dc53e6e2.patch patch -p3 < 442321f6d6619c0ff80770776f108d50dc53e6e2.patch CFLAGS=-g\ -ggdb make Dann kannst du wieder testen, das Problem sollte nicht mehr auftreten. Der Auslöser ist, dass der Client disconnected, wenn im Send Queue noch Antworten für den Client sind. In diesem Fall wird der Socket des Clients nicht richtig aus dem Event Loop entfernt. Was im Endeffekt dann dazu führt, dass Funktionen für einen Client aufgerufen werden, dessen Speicher schon längst freigegeben wurde => Crash. Es wird dann in Kürze eine neu brickd Version geben. Warum das Problem erst jetzt auftritt mag damit zusammenhängen, dass sich das Timing deines ganzen Aufbaus vielleicht etwas verändert hat, oder sich die Belastung etwas geändert hat, so dass es jetzt vorkommt, dass Clients disconnecten wenn brickd noch Antworten für sie hat.

Okay, da sind einige Invalid Reads zu erkennen im Valgrind Log. Leider kann Valgrind mit der brickd Version aus dem Debian Package keinen ordentlichen Backtrace erzeugen, so dass man sehen kann wo im Code das Problem ist. Daran hatte ich vorher nicht gedacht, sorry. Kannst du brickd selber kompilieren, so dass es Symbols usw. hat damit Valgrind besser anzeigen kann wo das Problem ist? Hier wie's geht: sudo apt-get install build-essential pkg-config libusb-1.0-0-dev libudev-dev pm-utils wget https://github.com/Tinkerforge/brickd/archive/v2.1.0.zip unzip v2.1.0.zip cd brickd-2.1.0/src/brickd CFLAGS=-g\ -ggdb make Danach liegt im aktuellen Verzeichnis der neue brickd. Und dann nochmal mit Valgrind: sudo valgrind --time-stamp=yes --log-file=valgrind.log ./brickd Zeitliche Zuordnung der Valgrind und brickd Ausgaben ist nicht unbedingt nötig, wenn Valgrind mir sagt wo im Code das Problem ist sollte das reichen, um es verstehen und beheben zu können. Aber es schadet nicht Valgrind einen Timestamp im Log ausgeben zu lassen. Der ist aber im Gegensatz zu brickd relative zur Startzeit von Valgrind.

Die Callbacks sind asynchron, wir verwenden dafür aber nicht process.nextTick(), denn wir verwendet die Callbacks der Socket Klasse. IPConnection.connect() erzeugt einen Socket, registriert zwei Funktionen für das Error und Connect Event und ruft dann Socket.connect() auf. Danach ist IPConnection.connect() durch und returned. Später ruft dann die Socket Klasse entweder die registrierte Error oder Connect Funktion auf vorauf hin die IPConnection entweder deine Error Funktion oder den Connected Callback aufruft. Alle Callbacks der Node.JS Bindings sind in dieser Weise an I/O Operationen gebunden. Alle I/O Operationen in Node.JS sind asynchron und die IPConnection nutzt das einfach. Wir brauchen kein process.nextTick() um asynchron Callbacks zu haben.

==24206== ERROR SUMMARY: 10000000 errors from 15 contexts (suppressed: 25 from 9) 10000000 Errors! Da ist irgendwas oberfaul. Es ist vom Aufbau von brickd her nicht möglich das diese Fehlermeldung zweimal für den gleichen Socket auftritt. Auch das es Fehlercode EBADF ist ist mit höchst Suspekt. Ich könnte mir vorstellen es reicht an einer Stelle passend eine der Datenstrukturen von brickd zu zerschreiben, dabei diese Problem zu erzeugen, den Rest aber weiterlaufen zu lassen. Starte Valgrind mal mit Logfile, damit dessen Ausgaben nicht in der Menge von brickd Meldungen verloren gehen: sudo valgrind --log-file=valgrind.log brickd

Laufen die Programme die die Anfragen machen durch oder startest du die für jede Anfrage neu? Wenn dein Programm durchläuft und ab und zu "vergisst" Sockets/IPConnections wieder zu schließen, dann könnte sich so eine Liste offener Verbindungen ansammeln. Diese würden dann vom Betriebssystem wieder geschlossen, wenn das Programm beendet wird. Da ich aber annehme, dass du das Protokoll von Hand mit einzelnen netcat Aufrufen sprichst kann das eigentlich nicht das Problem sein.

Sorry, das was ungeschickt formuliert. Valgrind gibt das alles an einem Stück aus, das sieht dann z.B. so aus: ==19182== Invalid write of size 4 ==19182== at 0x804838F: f (example.c:6) ==19182== by 0x80483AB: main (example.c:11) ==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) ==19182== by 0x8048385: f (example.c:5) ==19182== by 0x80483AB: main (example.c:11) Das Log sieht jetzt aus wie ich es erwarten würde, nach deiner Beschreibung. Connect und Disconnect schön abwechselnd. Im Fehlerfall sind dann aber im Log Häufungen von Disconnects, was ich komische finde. Das passt nicht so wirklich zum beschriebenen Verhalten deines Aufbaus.

Das steht in den technischen Daten: 4,8V bis 5,7V. Unter der Annahme du meinst Versorgung über den Mini-USB Stecker.

Okay, ich erwarte das Valgrind Invalid Read oder Write Operationen meldet wenn das Problem auftritt. Die Ausgabe von Valgrind dazu mit samt den Backtraces interessiert mich, um zu sehen wo das Problem her kommt. Ich habe mit deine Logs nochmal angesehen und zwei Dinge sind mir aufgefallen. Die letzten zwei Logausgabe bevor das Problem auftritt sind immer: 2014-07-11 21:22:16.454644 <I> <network|client.c:242> Client (S: 20, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-11 21:22:16.455385 <W> <network|client.c:495> Destroying client (S: 20, T: plain, P: 192.168.23.81, A: disabled) while 2 response(s) have not beed send Ein Client schließt seine Verbindung bevor brickd im alle Response Pakete schicken konnte. Auch ist auffällig, dass kurz vorher viele Verbindungen in sehr kurzer Zeit geschlossen werden: 2014-07-12 05:10:14.060499 <I> <network|client.c:242> Client (S: 44, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.060691 <I> <network|client.c:242> Client (S: 45, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.076709 <I> <network|client.c:242> Client (S: 17, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.077244 <I> <network|client.c:242> Client (S: 16, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.078239 <I> <network|client.c:242> Client (S: 18, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.079139 <I> <network|client.c:242> Client (S: 19, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.080047 <I> <network|client.c:242> Client (S: 20, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.080975 <I> <network|client.c:242> Client (S: 21, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer 2014-07-12 05:10:14.081860 <I> <network|client.c:242> Client (S: 22, T: plain, P: 192.168.23.81, A: disabled) disconnected by peer Da frage ich mich gerade wie das zustande kommt. Wie lange bleiben die Verbindungen der minütlich zugreifenden anderen Rechner bestehen?

Ich hab das Beispiel des Industrial Quad Relay Bricklet gerade getestet und es funktioniert. Wenn die UID richtig ist bleibt nicht mehr viel anderes was die Ursache sein könnte. Füge zum Testen mal nach "ipcon.connect(HOST, PORT);" folgende Zeile im Beispiel ein: iqr.setResponseExpectedAll(true); Wenn es Kommunikationsprobleme gibt sollte das Exceptions erzeugen.