photron

Habe es gerade so abgeändert im git. Die nächste Version wird diese Änderung beinhalten.

"global.window.Tinkerforge" ist redundant, es reicht auch "global.Tinkerforge" für das gleiche Ergebnis. Damit funktionieren die Bindings hier auch in einem einfachem WebWorker Test. Tinkerforge.js

Wenn es reicht dein Python Script neuzustarten, dann deutet das darauf hin, dass das Problem eher dort liegt. Ich hab mir dein Script angesehen, aber das ist auf den ersten Blick alles in Ordnung. Wenn das Problem auftritt, funktionieren die Buttons dann noch in Brick Viewer?

Da steht sich das perl Package mit einigen anderen Packages auf den Füssen. Ich denke, dass ist ein Bug im perl Package selbst. In dieser Situation verweigert apt-get die Arbeit, weil es erst diese Problem beseitigt haben will. Ich konnte das Problem reproduzieren und so auflösen: sudo dpkg --purge cpanminus sudo dpkg --purge liblocal-lib-perl sudo dpkg --purge libmodule-build-perl sudo dpkg --purge libjson-pp-perl sudo dpkg --purge perl-doc sudo apt-get -f install sudo apt-get upgrade Jetzt stehen sich systemd und systemd-shim im Weg: sudo dpkg --purge systemd-shim sudo apt-get -f install sudo apt-get install systemd-shim sudo apt-get upgrade

Kannst du denn noch auf das LCD schreiben, wenn die Callbacks nicht mehr funktionieren? Hängt das funktionierende Moisture Bricklet am gleichen Brick wie das LCD 20x4 Bricklet? Was musst du tun, damit die Callbacks wieder funktionieren? Den Brick neustarten, oder dein Programm neustarten, oder etwas anderes?

Hier hat das mal wer für AutoIt gemacht: http://www.tinkerunity.org/forum/index.php/topic,2706.msg17355.html

Wird es, mit fest 3,3V.

What's the SamplingPeriod? One different between WIFI and USB is the throughput. Typically, WIFI has less throughput than USB. If your SamplingPeriod is very small then the Bricklets might try to send more callbacks then the WIFI connection can handle. I assume you don't have USB connected to the stack while you're using WIFI, is this correct?

Dass heißt, du brauchst für dein eigentlichen Zeichnen kein OpenGL, sondern es geht dir darum die GPU zu verwenden. Für dein eigentliches Zeichnen würde auch QPainter reichen? Hast du mal eine Kombination aus QOpenGLWidget und QPainter getestet, wie hier beschrieben: http://doc.qt.io/qt-5/qopenglwidget.html#painting-techniques

Okay, jetzt können wir sicher sein, dass das Problem nicht von deinen OpenGL Headern kommt. Ich habe mit die Fehler noch mal genauer angesehen. Ich denke, dass du da zwei Probleme hast: Zum einen sind die OpenGL Header zu neu oder die Qt5 Version zu alt. Die OpenGL Header beinhalten Definitionen für OpenGL 4.3, damit scheint die Qt5 Version nicht zurecht zu kommen. Den einen Definitions-Konflikt kannst du möglicherweise lösen indem du diese Zeile #define GL_KHR_debug 1 in deinen Code einfügst, bevor zu irgendwelche anderen Header includest. Zum anderen will Qt5 auf dem RED Brick OpenGL ES 2 verwenden, du willst aber normales OpenGL verwenden. Das scheint sich auch nicht zu vertragen. Brauchst du normales OpenGL, oder könntest du auch OpenGL ES 2 verwenden?

Aus der Make Ausgabe sehe ich folgendes: - dein Programm bringt mindestens gl.h und glu.h mit - auf deinem RED Brick sind /usr/include/GL/gl.h, /usr/include/GL/glext.h, usw. vorhanden Teste bitte mal folgendes: - alle OpenGL Header (gl.h, glu.h, usw.) aus deinem Programmverzeichnis entfernen - in deinem Programm Code alle Includes für OpenGL (#include "gl.h" usw.) durch Includes dieser Form ersetzen: #include <GL/gl.h> Dadurch werden dann die OpenGL Header verwendet, die der RED Brick schon mitbringt. Denn es sieht für mich immer noch so aus als ob dein Problem ist, dass deine OpenGL Header und die vom RED Brick sich durch die Verwendung den Qt OpenGL Modules vermischen und die Fehler erzeugen.

Die OpenGL Header kommen also vom RED Brick aus /usr/include? Selbst wenn dem so ist, lösch die mal aus deinem Verzeichnis. Es muss dennoch gehen.

Schau an, lauter Compile Fehler im Zusammenhang mit OpenGL. Such mal in der Ausgabe nach "error:". Wenn ich das richtig sehe ist an allen Fehlern "../bin/glu.h" beteiligt. Hast du einen besonderen Grund warum du deinen eigenen glu.h (und wahrscheinlich auch gl.h) mitbringst? Entferne mal alle OpenGL Header die du selbst mitbringst, damit nur die aus /usr/include verwendet werden. Ich vermute, dass das Gemisch aus deinen und den System OpenGL Headern das Problem ist.

Tja, sieht an sich gut aus. So wie das Makefile gebaut ist müsste es alle Befehle ausgeben bevor es sie ausführt. Zeig mal die komplette Ausgabe von make. Falls es nicht den g++ Befehl anzeigt bevor es in ausführt, dann kannst du das Makefile editierten, um an diese Information zu kommen. In Zeile 428 echo ">>> $(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../bin/main.cpp <<<" zwischen diesen beiden Zeilen einfügen: ../bin/bricklet_io4.h $(CXX) -c $(CXXFLAGS) $(INCPATH) -o main.o ../bin/main.cpp Achte, darauf, dass die echo Zeile auch mit einem Tab eingerückt ist wie die $(CXX) Zeile. Worauf ich hinaus will. Normalerweise solltest du von g++ selbst eine Fehlermeldung bekommen. Das scheint aber hier nicht der Fall zu sein, sondern make gibt selbst diesen komischen Fehler aus. Daher meine Vermutung, dass der g++ Befehl an sich kaputt ist. Du kannst auch mal "make -d" ausführen, damit make dir mehr Debug Informationen ausgibt.

Das ist nicht der eigentliche Fehler, denke ich. Das muss vorher in der Ausgabe noch der richtige Fehler stehen. Bzw. zeig mal was in Makefile an Zeile 428 (plus 10 Zeilen davor und danach) steht, oder häng das ganze Makefile mal an.

Naja, der gleiche Fehler kann es ja nicht sein. Denn wenn du den windows.h Include entfernst hast, dann kann dieser ja nicht mehr an der Abwesenheit von windows.h scheitern. Tritt der Fehler jetzt an einer anderen Stelle auf, oder hast du nicht die richtige gl.h Datei editiert?

This should just work. WIFI and USB should not make a difference like this, Which callback is this? How do you power the stack when you use the WIFI Extension?

Ist es. gl.h versucht hier auf komische Art und Weise Windows zu detektieren. Wenn WINGDIAPI nicht definiert aber APIENTRY definiert ist dann will es windows.h includen. Dein Problem hier wird sein, dass irgendwer anders APIENTRY definiert. Das gl.h an diesem doch eher generischen Namen versucht Windows zu erkennen ist problematisch. Paste mal den Anfang der gl.h Datei bis zu der Stelle wo der Fehler auftritt, oder häng die ganze gl.h Datei an einen Post an. Entweder wird vor dieser Stelle ein anderer Header included, der APIENTRY definiert, oder APIENTRY wird im Compiler-Befehl per -D Option definiert. Dass gilt es zu finden und zu beheben. Oder du kannst gl.h hacken und #if !(defined(WINGDIAPI) && defined(APIENTRY)) durch #if 0 ersetzen und sehen wie weit du dann kommst.

Das sollte kein Problem sein. Ich wüsste gerade auf Anhieb nichts was dagegen spricht.

Link ist korrigiert. Der L/R Aufdruck auf dem Bricklet ist korrekt. Es war im Plugin vertauscht. Das ist aber schon vor 1,5 Jahren mit Version 2.0.2 behoben worden. Wahrscheinlich hast du Bricklets bekommen, die nicht auf dem letzten Softwarestand sind. Du kannst das also durch ein Update des Bricklet Plugins beheben.

Du musst beim Servo Brick zwischen der Ausgangsspannung und der Spannung des PWM-Steuersignals unterscheiden. Die Ausgangsspannung ist zwischen 2V und 9V einstellbar, aber sie ist für alle 7 Servos gleich. Die Spannung des PWM-Steuersignal-High-Pegels ist fix bei 5V. Der DC Brick gibt ein PWM Signal mit der Eingangsspannung als fixen High-Pegel aus. Über die Velocity kannst du den Dutycycle des PWM Signals einstellen und damit die durchschnittliche Ausgangsspannung zwischen 0V und der Eingangsspannung einstellen.

Das kann eigentlich nur am Magnetometer liegen. Versuch es noch mal zu kalibrieren. Was du tun musst, ist die maximale und minimale Magnetfeldstärke für alle 3 Achsen zu finden. Dazu jeweils jede Achse in positive und negative Richtung nach Norden richten und mit der IMU etwas kreisen, bis die Werte im Kalibrierungsfenster sich nicht mehr ändern. Falls das nicht hilft, versuch mal die IMU an einem anderen Ort zu benutzen. Möglicherweise hast du ungewöhnliche Magnetfeldstörungen an deinem Tisch.

Hast du den schon mal das PHP Beispiel angesehen, dass 4223 auf das Display schreibt? http://www.tinkerforge.com/de/doc/Software/Bricklets/SegmentDisplay4x7_Bricklet_PHP.html#simple Um die Uhrzeit anzuzeigen muss du dann in Zeile 24 die feste Auswahl der Ziffern 4 2 2 3 durch die Ziffern der aktuellen Uhrzeit ersetzen.

Loetkolben, ich denke nicht, dass du zwingend ein Programm schreiben muss. Unter Linux kannst du über das Dateisystem mit USB Devices arbeiten, Stichwort usbfs. Siehe /dev/bus/usb und /sys/bus/usb.

Was für Probleme hast du denn genau?