photron

Ich habe mir dein Programm angesehen. Dein Problem mit dem IO-16 Bricklet liegt daran, dass du zwei BrickletIO16 Objekte für die gleich UID mit der gleichen IPConnection erzeugst. Im MainWindow Konstruktor erzeugst du ein ControllerDevice mit UID gpL und ein ChannelDevice mit UID gpL. Beide leiten von Device ab und erzeugen dadurch zwei BrickletIO16 Objekte für die gleich UID. Intern hält die IPConnection eine Tabelle, die UID auf Brick/Bricklet Objekt abbildet. Wenn du bei gleicher UID und IPConnection ein weiteres BrickletIO16 erzeugst, dann verdrängt das neu Objekt das alte aus dieser Tabelle. Der Effekt davon ist, dass Setter-Aufrufe auf dem alten BrickletIO16 Objekt noch funktionieren, die Antworten für Getter-Funktionen aber immer dem neuen BrickletIO16 Objekt zugestellt werden. Dadurch bekommst du einen Timeout beim Aufruf einer Getter-Funktion auf dem alten BrickletIO16 Objekt. Das ist auch der Grund warum es hilft, wenn du das BrickletIO16 Objekt vor dem Getter-Aufruf neu erzeugst, weil diese dann das bisherige Objekt verdrängt und die Antworten zugestellt bekommt. Wenn ich das richtig sehe, dann soll das ControllerDevice sich mit Port B und das ChannelDevice mit Port A eines IO-16 Bricklets befassen. Damit das klappt kannst du deiner Device Klasse beibringen, dass sich zwei Device Objekte ein BrickletIO16 Objekt teilen.

Dein Programm aktiviert den Count Callback nicht (siehe Callback Beispiel). Wenn du in brickv den Tab des Bricklets öffnest, dann aktiviert brickv den Callback und dadurch erhält in auch dein Programm. Dir fehlt folgende Zeile in __init__: self.encoder.set_count_callback_period(50)

Brick Daemon 2.1.1 Add live debug log view to logviewer.exe on Windows Include signed version of the Brick bootloader driver for Windows Workaround race condition in USB hotplug handling on Linux Fix crash if client with pending responses disconnects Fix possible mismatch while handling responses for identical requests Avoid broadcasting unexpected responses in most cases Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.1.1 Live Debug Log Ansicht zu logviewer.exe für Windows hinzugefügt Signierte Version des Brick Bootloader Treibers für Windows hinzugefügt Race Condition in der USB Hotplug Behandlung auf Linux vermieden Absturz behoben Im Falle, dass ein Client die Verbindung trennt bevor alle Responses gesendet wurden Mögliche Falschzuordnung in der Response Behandlung für identische Requests behoben Broadcast unerwarteter Antworten wird in den meisten Fallen jetzt vermieden Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Du machst da keinen Kurzschluss, solang du den Pin an dem der Schalter hängt nicht als Ausgang konfigurierst. Es ist kein Problem, dass so auch über längere Zeit zu betreiben. Dein Aufbau ist einer der typischen Anwendungsfälle der IO-4.

Loetkolben, der Kreis mit dem A drin ist ein Amperemeter. Das soll die Arbeitsweise der IO-4 symbolisiern, weshalb des auch in der IO-4 Box ist. tfRookie, wenn du einfach nur messen willst ob ein Schalter offen oder geschlossen ist, dann kannst den Schalter direkt zwischen einen der vier Pins und GND der IO-4 anschließen. Kein Vorwiderstand nötig. Die Pins der IO-4 sind standardmäßig als Input Pull-Up konfiguriert. Wenn du ihren Wert per get_value() Funktion ausließt bekommst du High zurückgegeben. Wenn der angeschlossene Schalter offen ist, dann ist es für die IO-4 als wäre er nicht da, get_value() liefert High. Wenn der Schalter geschlossen ist wird der Pin mit GND verbunden, get_value() liefert Low. Du kannst statt get_value() auch den Interrupt Callback verwenden, dann teilt dir die IO-4 von sich aus Änderungen des Pin-Zustands mit.

Das Linux für den RED Brick basiert auf Debian.

Du kannst eine armhf VM auf einem x86 Host aufsetzen. Das geht allerdings meines Wissens nach nicht mit Virtual Box. Dafür brauchst du dann z.B. QEMU, das dann armhf auf x86 emulieren kann.

Deine VM wird höchstwahrscheinlich als x86 laufen und nicht als armhf. Daher wirst du auch von Linux aus noch für die Architektur des RED Brick Cross-Compilen müssen. Das Free Pascal Wiki hat einen Artikel darüber: http://wiki.freepascal.org/Setup_Cross_Compile_For_ARM Auf dem RED Brick wird der Free Pascal Compiler installiert sein, wie ihn auch Lazarus verwendet. Daher sollten deine Units auf dem RED Brick kompilierbar sein.

Du wirst Binaries direkt übertragen können. Das setzt aber voraus, dass du auf dem deinem Rechner auch Binaries für Linux ARM Hard-Float erzeugen kannst. Bei Java und C# oder den interpretierten Sprachen wie Python oder PHP ist das standardmäßig gegeben. Bei Delphi oder C muss du dazu dann aber Cross-Compilen. Davon hält dich keiner ab, ist aber nicht ganz so leicht. Daher ist auch geplant, dass du deinen Source Code überträgst und auf dem RED Brick kompilierst.

Ahhh! Sorry, I totally misunderstood your problem. Everything is working, except from the Perl example. Okay, now I see what your problem is. There is a problem in our Perl example for the Remote Switch Bricklet. It is calling the switch_socket() function. This function is there for backward compatibility only. It should actually call the switch_socket_a() function for type A devices. But you have a type B device (ITL-210). You need to call switch_socket_b() function. Actually you need to call the dim_socket_b() function, because the ITL-210 is a dimmer. You need to replace this line in the example $rs->switch_socket(42, 23, $rs->SWITCH_TO_ON); with this line $rs->dim_socket_b(1234, 1, 7); to set the dimmer value to 7.

2014-07-29 12:38:07.998117 <D> <hardware|hardware.c:102> No stacks connected, dropping request (U: 1, L: 8, F: 254, S: 2, R: 0) According to brickd you don't have any Bricks connected to USB. There was a problem with the USB host on original Beagle Bone, Bricks connected to it didn't work properly due to some USB problem. Maybe the Beagle Bone Black still has this problem, I don't know. Things you can test: - Does it work if you connect the Brick directly to your PC instead of the Beagle Bone? - Do you have an USB hub at hand to connect between the Beagle Bone and the Brick?

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