photron

Du möchtest also mit 3x4 Touch Pad die Funktion des Rotary Potis ändern. Wenn die Helligkeitstaste gedrückt wurde soll ab dann das Poti die Helligkeit einstellen. Wenn die Farbetaste gedrückt wurde soll ab dann das Poti die Farbe einstellen. Das kannst du so lösen: MODE_BRIGHTNESS = 1 MODE_COLOR = 2 def cb_position(self, position): if self.mode == MODE_BRIGHTNESS: self.set_brightness(position + 150) elif self.mode == MODE_COLOR: self.set_color(position + 150) Du hast eine mode Variable die auf MODE_BRIGHTNESS oder MODE_COLOR gesetzt ist. Dein Programm reagiert auf das Drücken der Helligkeits- und Farbetaste und setzt dann mode auf MODE_BRIGHTNESS oder MODE_COLOR. In der cb_position() Funktion wird dann abhängig von mode deine set_brightness() oder set_color() Funktion aufgerufen die dann Helligkeit und Farbe abhängig von der aktuellen Position des Potis einstellen.

Du versorgst den problematischen Stack also über den DC Brick Motor Ausgang mit 5,1V. Wie hast du den DC Brick eingestellt (Velocity, PWM Frequency, Drive Mode, Acceleration) und mit welcher Spannung versorgst du den DC Brick Input Anschluss, damit da am Ende 5,1V am Motoranschluss herauskommen? Aus einem USB Anschluss kommen normalerweise glatte 5V. Beim DC Brick kannst du 5V am Motoranschluss aber eigentlich nur durch PWM erreichen. Es kann sein, dass ein Brick das nicht gut verträgt.

Von deiner Beschreibung des Programms her sollte das funktionieren. Standardmäßig ist die Debounce Period (siehe set_debounce_period) auf 100ms gestellt. Wenn der Endschalter also weniger als 100ms gedrückt ist kann es passieren, dass das nicht als Interrupt angesehen wird. Andere Möglichkeit wäre, dass der Endschalter oder die Verkabelung mechanisch oder elektrisch nicht in Ordnung ist und einen Wackelkontakt hat. Dadurch kann der Endschalter dann gedrückt werden, ohne dass das elektrisch bei der IO-16 ankommt.

Die cb_position() Funktion im Rotaty Poti Callback ist nicht dazu da, um von dir aufgerufen zu werden, sondern um von den Bindings aufgerufen zu werden, wenn ein Position Callback von Bricklet eintrifft. Du hast also keine Kontrolle darüber wann die cb_position() Funktion aufgerufen wird. Wenn du die aktuelle Position abfragen willst kannst du einfach die get_position() Funktion aufrufen, statt den Position Callback zu verwenden, wie in diesem Beispiel: http://www.tinkerforge.com/de/doc/Software/Bricklets/RotaryPoti_Bricklet_Python.html#simple

Versuch mal den untersten Master Brick des problematischen Stacks auszutauschen, um zu sehen ob es an diesem speziellen Brick liegt. Versuch mal den problematischen Stack anders mit Strom zu versorgen, also nicht über einen DC Brick, um zu sehen ob das bei diesem speziellen Stack ein Problem macht. Verusch mal den Aufbau zu verkleinern. Tritt das Problem auch auf, wenn du mit dem problematischen Stack alleine sprichst ohne die anderen Stacks im Bus? Tritt das Problem auch auf, wenn du den problematischen Stack auf Master Brick und RS485 Extension verkleinerst? Bezüglich der Sequence Number meinte ich, ob dir der Stack immer erst wieder bei einer bestimmten Sequence Number antwortet. Also erst wenn du mit er Sequence Number z.B. bei 123 angekommen bist.

Ist an dem Stack der länger braucht irgendetwas anders als an den anderen Stacks? Andere Master Brick Firmware, andere Bricks oder Bricklets im Stack? Mit welcher Baudrate kommunizierst du? Welche Sequence Number hat die erste Antwort die du bekommst? Ist es immer die gleiche Sequence Number?

Du kannst die Packages auf dem PC herunter laden, auf den RED Brick kopieren und dann dort installieren. Hier ist die Liste: libaacs0 libasn1-8-heimdal libass5 libbluray1 libbs2b0 libcdio-cdda1 libcdio-paranoia1 libcdio13 libdv4 libdvdnav4 libdvdread4 libenca0 libfaad2 libfribidi0 libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libkrb5-26-heimdal libldb1 liblircclient0 liblua5.2-0 libmpg123-0 libntdb1 libpostproc52 libquvi-scripts libquvi7 libroken18-heimdal libsmbclient libtalloc2 libtdb1 libtevent0 libvdpau1 libwbclient0 libwind0-heimdal mplayer2 python-talloc samba-libs Diese kannst du für Debian jessie armhf hier herunterladen (<PACKAGE> durch den Package Namen ersetzen): https://packages.debian.org/jessie/armhf/<PACKAGE>/download Und dann auf dem RED Brick mit folgendem Befehl jedes Package einzeln installieren: sudo dpkg -i <PACKAGE> Einfacher ist es aber wenn der RED Brick selbst direkt Internetverbinding hat. Eigentlich kommt dafür nur QEMU in Frage. Das Problem ist QEMU kann zwar ARM emulieren, aber der A10s SoC ist nicht in der QEMU Machine Liste für ARM. Ich habe andere ARM SoCs probiert aber es bootet nicht.

Du kannst VLC nachinstallieren, ich empfehle aber mplayer zum Testen. Am einfachsten ist es wenn der RED Brick eine Internet Verbindung hat und ein Display angeschlossen ist. RED Brick per USB am PC anschließen und im RED Brick Console Tab im Brick Viewer per apt-get mplayer installieren. sudo apt-get update sudo apt-get install mplayer2 Dann mplayer so starten. DISPLAY=:0 mplayer tv:// Wenn alles klappe sollte das Kamerabild auf dem Display angezeigt werden.

Eigentlich sollte eine Logitech Pro 9000 direkt funktionieren. Der uvcvideo Treiber ist vorhanden und damit solle auch eine Logitech Pro 9000 funktionieren. Ich habs gerade mit einer No-Name Webcam probiert und die wird ohne Problem gefunden. Beziehungsweise mal anders: Warum denkst du, dass du erst einen extra Treiber installieren musst?

Das installieren von qt5-default deinstalliert wirklich libsunxi-mali-x11 und xserver-xorg-video-sunximali. Bedingt durch einen Konflikt zwischen libsunxi-mali-x11 und libegl1-mesa-drivers. Das sollte lösbar sein.

Ist das die ApplicationException, die du selbst in refreshCameraList() wirfst, wenn videoDevices.Count == 0 ist?

Der Hardwareaufbau wird für dein Projekt funktionieren. Wenn du den Stapel nicht über den USB Anschluss mit 5V versorgen kannst, dann kannst du alternative eine Step-Down Power Supply drunter stecken und dort 6-27V einspeisen. Wenn du eh schon 24V Gleichstrom für die Heizmatte hast könntest du mit diese 24V auch die Step-Down Power Supply versorgen. Den OK Ausgang kannst du auf viele verschiedene Weisen realisieren. Das hängt dann auch davon ab was wiederum an diesem OK Ausgang angeschlossen werden soll. - Mit dem IO-4 Bricklet kannst du 3,3V (high) oder 0V (low) ausgeben. - Mit dem Dual Relay Bricklet oder Industrial Quad Relay Bricklet kannst du Relaiskontakte öffnen und schließen. - Mit dem Analog Out Bricklet kannst du analog 0-5V ausgeben. Der Sollwert kann auch über verschiedene Arten eingestellt werden. Das hängt dann auch davon ab was wiederum an diesem Sollwert Eingang angeschlossen werden soll. - Mit dem Voltage/Current Bricklet kannst du 0-36V messen und dadurch den Sollwert als analoge Spannung vorgeben. - Ein IO-4 Bricklet kannst du als 4 Bit Eingang verwenden und so 16 Sollwerte abbilden. Mit einem IO-16 Bricklet sogar 65536 Sollwerte. Wenn du genauer beschreiben kannst wie der OK Ausgang und oder Sollwert Eingang funktionieren sollen, bzw. wie sie genau verwendet werden sollen, dann kann ich dir da auch noch deinstallierter Vorschläge machen.

Wie hast du Qt installiert? sudo apt-get install qt5-default Vielleicht ist das Problem dadurch entstanden. Wenn ja, dann können wir das vielleicht auf Dauer beheben.

Ups, falscher URL. Mit dem hier gehts besser: https://github.com/Tinkerforge/red-brick/raw/master/image/patches/root-fs/full/tmp/mali-gpu/xserver-xorg-video-sunximali_1.0-4_armhf.deb Lösch vorher die alte xserver-xorg-video-sunximali_1.0-4_armhf.deb Datei sonst speichert wget die neue mit einem .1 am Ende.

Sehr komisch. Hat mit exakt dem Image der Desktop vorher funktioniert und ist kaputt gegangen, oder hast du den Desktop gerade erst eingeschaltet und er hat direkt nicht funktioniert? Die fehlende Datei kommst aus diesem Package: https://github.com/Tinkerforge/red-brick/blob/master/image/patches/root-fs/full/tmp/mali-gpu/xserver-xorg-video-sunximali_1.0-4_armhf.deb Es reicht wahrscheinlich das Package auf dem RED Brick herunter zu laden und per dpkg erneut zu installierst: wget https://github.com/Tinkerforge/red-brick/raw/master/image/patches/root-fs/full/tmp/mali-gpu/xserver-xorg-video-sunximali_1.0-4_armhf.deb sudo dpkg -i xserver-xorg-video-sunximali_1.0-4_armhf.deb Edit: URL korrigiert.

[ 62.443] (II) LoadModule: "fbturbo" [ 62.445] (WW) Warning, couldn't open module fbturbo [ 62.445] (II) UnloadModule: "fbturbo" [ 62.445] (II) Unloading fbturbo [ 62.445] (EE) Failed to load module "fbturbo" (module does not exist, 0) Der X-Server kann den Framebuffer Driver names fbturbo nicht finden/laden. Der muss hier liegen: /usr/lib/xorg/modules/drivers/fbturbo_drv.so Ist das bei dir der Fall?

Für einen per USB angeschlossenen Brick sendet der Brick Daemon einen Enumerate-Disconnected Callback, wenn er mitbekommt, dass der Brick von USB getrennt wurde. Hast du mal ein anderes USB Kabel und/oder USB Anschluss am PC probiert? Wackelkontakt der USB Verbindung könnte ein Problem sein. Welche Firmware Version ist auf den betroffenen Master Bricks?

Der_Kanzler, das Problem in deinem Programm ist erst einmal, dass du in setNewListBoxContent() versuchst den ersten Eintrag der Liste auszuwählen: lstDeviceList.SelectedIndex = 0 Das erzeugt eine ArgumentOutOfRange Exception, die vermutlich daher kommt, dass videoDevices leer ist und daher kein Eintrag zu lstDeviceList hinzugefügt wird. Was dann dazu führt, das es in lstDeviceList keinen Eintrag an Index 0 gibt, der ausgewählt werden könnte. Du solltest da also auch den Fall behandeln, dass keine Webcam angeschlossen ist. Dann verschwindet dieser Fehler auch auf Windows. Jetzt zum eigentlichen Problem. Ich habe mir gerade kurz AForge angesehen. Hier der wichtige Satz aus deren Dokumentation: DirectShow kommt von Microsoft, sprich ist erstmal Windows spezifisch. Auf dem RED Brick läuft aber Linux. Ich bin noch nicht draus schlau geworden ob Mono das auf Linux unterstütz. Was du mal testen kannst ist in refreshCameraList() die ApplicationException nicht einfach zu fangen und zu ignorieren, sondern wie in setNewListBoxContent() per Messagebox auszugeben. AForge wirft intern auch an ein paar Stellen ApplicationExceptions. Vielleicht wirft AForge eine ApplicationException mit einem passenden Hinweis.

Welche Konsole siehst du denn? Das kannst du mittels "tty" Befehl in der jeweiligen Konsole ermitteln. Es gibt tty1 und tty2. Auf tty2 sollte der Desktop starten. Du kannst mit Ctrl+Alt+F2 nach tty2 wechseln. Da sollte entweder der X-Server laufen oder das X-Server Log zu sehen sein. Du kannst dir im Brick Viewer über den Import/Export Tab auch das X-Server Log (Xorg.0.log) ansehen und hier posten, wenn du daraus nicht schlau wirst.

Habe ich das richtig verstanden? Am Anfang funktioniert alles wie es soll: Die 4 Taster funktionieren, das Backlight kann ein- und ausgeschaltet werden und es wird Text angezeigt wie im Brick Viewer eingegeben. Irgendwann funktionieren dann nur noch die Taster, aber das Display selbst nicht mehr. Erst nach einem Reset des Master Bricks funktioniert alles wieder. Nein, das ist kein bekanntes Problem.

Könnte man. Ich setze das mal auf die TODO Liste, was jetzt aber nicht heißt, dass es in der nächsten Brick Viewer Version schon enthalten sein wird

Die Step-Down Power Supply arbeitet als Abwärtswandler (Step Down Converter), daher der Name. Die überflüssige Spannung wird nicht wie bei einem Längsregler (z.B. dem LM7805 Festspannungsregler für 5V) in Abwärme umgesetzt. Daher sollte keine zusätzliche Kühlung nötig sein.

Ich nehme an du hast eine wichtige Zeile im Interrupt Beispiel übersehen: # Enable interrupt on pin 2 of port a io.set_port_interrupt('a', 1 << 2) Standardmäßig sind alle Interrupts aus. Diese Zeile aktiviert den Interrupt Callback für Pin 2 auf Port A. Wenn du das in deinem Programm nicht konfigurierst dann bekommst du auch keine Callbacks. Es funktioniert aber, wenn du im Brick Viewer den IO-16 Tab auswählst, weil dann der Brick Viewer set_port_interrupt() aufruft um selbst den Interrupt Callback zu verwenden. Wenn du den Tab wieder abwählst stellt Brick Viewer den Interrupt Callback wieder aus. Sprich Brick Viewer kommt laufenden Programmen in die Quere, weil er die Callbacks umkonfiguriert. Darüber sind schon einige Leute gestolpert, daher haben wird das für die nächste Brick Viewer Version umgebaut, so dass Brick Viewer dann Callbacks nicht mehr umkonfiguriert.

Die 4 Bit Sequence Number in TCP/IP Paket folgt einfachen Regeln: - Die Anfragen die du sendest dürfen 0 als Sequence Number nicht verwenden, da diese für Callback Antworten vorbehalten ist. - Mit welcher Sequence Number du anfängst spielt im Moment (noch) keine Rolle. Es spielt auch im Moment (noch) keine Rolle in welcher Reihenfolge du die Sequence Numbers verwendest. Am besten folgst du aber dem was die API Bindings tun. Die fangen mit 1 an und erhöhst dann für jede neue Anfrage um +1. Also 1, 2, ..., 14, 15, 1, 2, ... Bei der 8 Bit Sequence Number im Modbus Paket gibt es keine ausgenommenen Werte. Du fängst mit 0 an und erhöhst für jeden neuen Anfrage-Antwort-Zyklus um +1. Also 0, 1, ..., 254, 255, 0, 1, ... Nein, ein Master ACK hat eine "empty message" als Payload: 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00

Was du auch noch ausprobieren kannst ist den Brick per brick-flash-cmd und --no-restart zu flashen und den Reset danach ohne brick-flash-cmd zu triggern, damit Python, pySerial usw. aus der Gleichung raus sind. Solange der Brick im Bootloader ist kannst du einen Reset auslösen indem du an das /dev/ttyACM0 Device folgenden String sendest: N#W400E1408,A5000A09#W400E1400,A500000D# Wie gesagt mir gehen die Ideen aus. Daher ist das hier auch nur ein weiterer Strohhalm Als Variation kannst du auch testen den Brick direkt zu resetten, ohne ihn zuvor zu flashen.