photron

Zuerst solltest du die Signatur der cb_temperature Funktion korrigieren. Sie muss so sein: void cb_temperature(int16_t temperature, void *user_data) Dann brauchst du in der Callback Funktion die Temperatur auch nicht mehr zu erfragen, denn der Callback liefert sie dir. Dann solltest du cb_temperature nicht mehr aus on_verticalSliderlicht_actionTriggered heraus aufrufen. Wenn du hier die Temperatur abfragen und anzeigen solltest du dafür eine eigene Funktion erstellen die die Temperatur abfragt und anzeigt, anstatt die Callback Funktion dazu zu verwenden. Wenn dann die Callback Funktion so ist wie sie eigentlich sein sollte, dann kann es ans eigentliche Problem gehen, die Temperatur auf einem QLabel anzuzeigen. Dazu sind zwei Probleme zu lösen. 1) Die cb_temperature Funktion muss auf das MainWindow zugreifen können. 2) Die cb_temperature Funktion wird aus einem Thread aufgerufen. Qt GUI Elemente dürfen aber nicht aus Threads heraus benutzt werden. Das lässt sich aber alles lösen. Für Problem 1) kann das user_data Parameter der cb_temperature Funktion benutzt werden. du übergibst als letztes Parameter this an die temperature_register_callback Funktion. Dann bekommt die cb_temperature Funktion diese als user_data Parameter übergeben: void cb_temperature(int16_t temperature, void *user_data) { MainWindow *that = (MainWindow *)user_data; // ... } // ... temperature_register_callback(&t,TEMPERATURE_CALLBACK_TEMPERATURE,(void*)cb_temperature,this); TO BE CONTINUED...

Schaltfrequenzen im kHz Bereich, kannst du mit unserem KS33 SSR für DC 50V/80A nicht erreichen. Das hat eine maximale Einschaltzeit von 1ms und Ausschaltzeit von 0,5ms. Dadurch könnte es theoretisch mit maximal 666Hz geschaltete werden. Praktisch sieht das anders aus. Wir haben es mit 400Hz bei 10A Last getestet und die Hitzeentwicklung ist so enorm, dass wir den Test nach einigen Sekunden abgebrochen haben. Wir haben dann den Hersteller gefragt und der rät dazu 30Hz nicht zu überschreiten. Unabhängig von den Einschränkungen durch das eingesetzte SSR wirst du Schaltfrequenzen im kHz Bereich nicht erreichen können, weil du dem Bricklet nur 1000 Nachrichten pro Sekunde schicken kannst.

Brick Viewer 2.1.2 Add support for Color, NFC/RFID and Solid State Relay Bricklet Rename main.exe to brickv.exe on Windows Make rainbow work better on small LED counts and add moving-dot mode to LED Strip Bricklet plugin Allow double click anywhere in a device tree row to jump to the corresponding tab Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.4, C# 2.1.2, Delphi/Lazarus 2.1.2, Java 2.1.2, JavaScript 2.0.2, LabVIEW 2.1.2, Mathematica 2.1.2, MATLAB/Octave 2.0.2, Perl 2.1.2, PHP 2.1.2, Python 2.1.2, Ruby 2.1.2, Shell 2.1.2, Visual Basic .NET 2.1.2 Add support for Color, NFC/RFID and Solid State Relay Bricklet [all] Rename bindings/ folder to source/ in ZIP file [C/C++, Delphi] Replace System.console() usage with an Eclipse compatible pattern in examples [Java] Move NPM package into nodejs/ folder of ZIP file [JavaScript] Add main Tinkerforge.js script to simplify direct usage of the Node.js source code [JavaScript] Only use MSG_NOSIGNAL if it's really defined [Perl] Remove CPAN package from ZIP file, include relevant files into the source/ folder [Perl] Get rid of the egg and easy_install, use setuptools directly or pip instead [Python] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, Visual Basic .NET

Brick Viewer 2.1.2 Support für Color, NFC/RFID and Solid State Relay Bricklet hinzugefügt main.exe in brickv.exe umbenannt auf Windows Regenbogen-Modus für das LED Strip Bricklet funktioniert besser bei wenigen LEDs und Moving-Dot-Modus hinzugefügt Doppelklick irgendwo in einer Zeile Der Device-Tabelle springt zum entsprechenden Tab Downloads: Windows, Linux, Mac OS X

Bindings: C/C++ 2.1.4, C# 2.1.2, Delphi/Lazarus 2.1.2, Java 2.1.2, JavaScript 2.0.2, LabVIEW 2.1.2, Mathematica 2.1.2, MATLAB/Octave 2.0.2, Perl 2.1.2, PHP 2.1.2, Python 2.1.2, Ruby 2.1.2, Shell 2.1.2, Visual Basic .NET 2.1.2 Support für Color, NFC/RFID und Solid State Relay Bricklet hinzugefügt [alle] bindings/ Ordner in der ZIP Datei in source/ umbenannt [C/C++, Delphi] System.console() Aufruf in Beispielen mit einem zu Eclipse kompatiblen Aufruf ersetzt [Java] NPM Package in den nodejs/ Ordner der ZIP Datei verschoben [JavaScript] Tinkerforge.js Script zur einfacheren direkten Nutzung des Quelltexts der Node.js Bindings hinzugefügt [JavaScript] MSG_NOSIGNAL wird nur noch dann verwenden wenn es auch definiert ist [Perl] CPAN Package aus der ZIP Datei entfernt, stattdessen Makefile.PL im source/ Ordner [Perl] Python egg aus der ZIP entfernt, stattdessen setuptools direkt oder pip verwenden [Python] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, Visual Basic .NET

Das aktuelle Verhalten beim Überschreiben von Objekten können wir nicht so einfach ändern, da sich existierende Programme darauf verlassen könnten. Was wir aber machen können ist beim Aufruf von Gettern eines überschriebenen Objekts eine spezielle IchWurdeÜberschriebenException zu verwenden, statt einer TimeoutException. Dann ist dies leichter zu erkennen.

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