photron

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.

Verwendest du im Beispiel auch die richtige UID deines Bricklets?

Speed ist die Anzahl an LEDs die sich der Dot pro Frame bewegt. Das hat nichts mit der Frame Duration zu tun.

Diese beiden Zeilen sind interessant: 2014-07-12 05:10:14.277472 <E> <network|client.c:260> Could not receive from client (S: 7281224, T: plain, P: P^Mo, A: disabled), disconnecting client: EBADF (9) 2014-07-12 05:10:14.334119 <E> <network|client.c:260> Could not receive from client (S: 7281224, T: plain, P: PTî¶PTî¶23.81, A: disabled), disconnecting client: EBADF (9) "S: 7281224" heißt der File Descriptor des Sockets diese Clients hat einen Wert von 7281224, das ist sehr hoch und ungewöhnlich, daher kommt da dann auch ein EBADF (ungültiger File Descriptor) als Fehler bei rum. "P: PTî¶PTî¶23.81" ist der Peername des Clients, da sollte eine IP Adresse stehen, das sieht aber nach Schrott aus. Das sieht auf den ersten Blick nach Heap Corruption aus. Irgendwie bringst du brickd dazu irgendwo falsch im Speicher herumzuschreiben. Kannst du das Problem reproduzieren? Es wäre hilfreich dazu ein Valgrind Log zu sehen. Dazu brickd manuell mit Valgrind starten: sudo valgrind brickd

Ich habe gerade mal ein paar neue dinge dem Brick Viewer hinzugefügt: - "Show Black" Knopf - Gradient funktioniert jetzt auch mit einer LED und besser mit geringen LED Zahlen - Gradient läuft anders herum - "Moving Color Dot" Mode hinzugefügt Ich nehme an du hast noch deinen git Clone von brickv, dann kannst du das gleich testen

Die IE Meldungen werden von Windows SmartScreen kommen. Der "neue" Treiber ist der alte Atmel Bootloader Treiber für die Bricks, den Atmel jetzt in einer signierten Version bereitstellt, so dass er auch auf Windows 8 ohne Umwege installiert werden kann und frühere Windows Versionen sich nicht mehr über einen nicht-signierten Treiber beschweren. Mal sehen was wir aus deinen LED Strip Ideen machen. Dazu melde ich mich dann später nochmal

Schau bitte mal ins brickd Log auf dem Raspberry Pi: /var/log/brickd.log Falls du daraus nicht schlau wirst, dann kannst du das auch hier posten, damit wir einen Blick darauf werfen können.

Okay, Version 2.1.1 ist jetzt im Sonatype OSS Repository angekommen: https://oss.sonatype.org/content/repositories/releases/com/tinkerforge/tinkerforge/ Es ist auf http://search.maven.org/ noch nicht zu finden, das sollte in Kürze aber auch gehen.

Sorry, über die ganze RED Brick Entwicklung ist das hier irgendwie hinten runtergefallen Ich hab bei Sonatype jetzt ein neues Projekt für die Bindings beantragt und mein Maven Setup für das Projekt nach deren guter Anleitung konfiguriert. Das sollte in den nächsten Tage also was werden

Android Apps sind in Java geschrieben. Brick Viewer ist aber in Python mit Qt als GUI Bibliothek. Man müsste entweder brickv in Java neuschreiben, oder den Python Code für Android flott machen. Es gibt da wohl Projekt für Python auf Android. Das ist aber alles nicht mal eben und dann ist das GUI Layout von brickv auch nie für Smartphones gedacht gewesen. Erwarte also in nächster Zeit kein Brick Viewer Android App Schau dir aber mal den Prototypen von Brick Viewer im Browser an: www.brickv.com. Allerdings werden da noch nicht alle Brick und Bricklet und Funktionen unterstütz. Das ist in JavaScript und recht leicht zu erweitern.

2.1.3 ist veröffentlicht.

Bindings: C/C++ 2.1.3 Redeklaration von strnlen in einigen MinGW Umgebungen behoben Download: C/C++