photron

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.

Da gehen mir langsam die Ideen aus Es funktioniert, wenn brick-flash-cmd am Ende den automatischen Reset weglässt und der Brick dann extern (z.B. durch USB ab- und anstecken) neugestartet wird. Es funktioniert nicht, wenn brick-flash-cmd am Ende den automatischen Reset macht, auch dann nicht wenn davor 5 Sekunden gewartet wird. Der Brick startet zwar neu (das Reset Kommando ist angekommen), aber der PC hat es nicht überlebt. Aber ein Reset aus Brick Viewer heraus funktioniert. Ich denke daher, dass das Problem eher PC seitig als Brick seitig ist. Ich denke es hat auch nichts damit zu tun, wie der Brick an USB angeschlossen ist, oder was sonst noch so an USB hängt. Meine Hoffnung war, dass das ein Timing Problem wäre und ein kurzes Sleep helfen würde. Dem ist wohl nicht so. Ein Unterschied zwischen Brick Viewer Reset und brick-flash-cmd Reset ist folgender: Wenn Brick Viewer den Reset auslöst ist der Brick nicht im Bootloader und die Kommunikation läuft über eine vendorspecific USB Device. Wenn brick-flash-cmd den Reset auslöst ist der Brick im Bootloader und die Kommunikation läuft über ein CDC ACM USB Device. In beiden Fällen führt ein Reset dazu, dass das jeweilige USB Device verschwindet während es gerade für Kommunikation geöffnet ist. Ich könnte da jetzt nach Strohhalmen greifen, einen Kernel Bug herbeireden und behaupten, dass im CDC ACM Fall sich der Kernel beim Verschwinden des USB Devices auf die Nase legt und den Rest des Systems mitnimmt. Von welcher Kernel Version reden wir hier überhaupt? Hast du mal in die Kernel Logs geschaut, ob da irgendwas hierzu drin steht?

ICH? API? Ich frage den Stack per TCP aus der Ferne ab und nutze die API der Bindings nicht. Daher kann ich das so nicht nachstellen. Doch, doch, auch du nutzt die API, wenn auch nicht über Bindings Ich spreche von Function ID 243 im TCP/IP Protokoll. Die API Bindings machen ja nichts weiter als Pakete zu erzeugen und diese zu senden und empfangen. Genau das tust du ja auch, aber von Hand. Sprich auch du kannst den Brick per API mittels Function ID 243 resetten. Die Art und Weise wie im Mikrocontroller des Bricks der Reset ausgelöst wird ist immer gleich, egal ob du im Brick Viewer den Reset Button klickst oder per API Bindings die Reset() Funktion aufrufst oder manuell ein TCP/IP Paket mit Function ID 243 schickst oder brick-flash-cmd nach dem Flashen den Brick per Registerzugriff neustartet. Daher die Hypothese: Wenn ein Reset per Software funktioniert, dann kann der Reset an sich nicht das Problem sein. Heikel ist das falsche Wort, aber bei jedem Hardreset eine PC, und das noch in der Ferne, laueft einem Gaensehaut ueber den Ruecken, zumal es sich in diesem Fall noch um ein Flashmedium handelt. Das System braucht mit zweimaligem Reboot und Filecheck gerne 10 Minuten bis die Pings wieder beantwortet werden. Das ist eine seeeeeeehr lange Zeit wenn man darauf wartet. Das System ist aber nicht lebensnotwendig und so werden wir es mal antesten. Bei solchen Wartezeiten macht das keinen Spaß, das ist verständlich.

Das Script resettet den Brick auf die gleiche Weise wie die Reset() Funktion aller Bricks in den API Bindings. Meine Frage hier wäre: Wenn du den Brick über die API Bindings resettest tritt das Problem dann auch auf? Meine Erwartung ist, dass ein Reset per Software funktioniert und dass das Problem nicht durch den Reset an sich ausgelöst wird. Ich habe dir eine weiter Version angehängt. Diese hat jetzt ein --restart-delay Argument: ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --restart-delay 500 Damit wird vor dem Restart 500 Millisekunden gewartet. Meine Erwartung ist, dass das einen Unterschied macht, da ich vermute, dass das Problem durch die engen zeitliche Abfolge der einzelnen Schritte entsteht. Dabei setzte ich voraus, dass nicht schon ein Neustart per API Reset() Funktion das Problem erzeugt Wenn es dir zu heikel ist das zu testen, dann können wir auch hier stoppen und uns mit der Erkenntnis begnügen, dass das Problem ohne Reset am Ende nicht auftritt. Dann würde ich einfach dem Script in der nächsten Version die --no-restart Option mitgeben und der Brick muss dann nach dem Flashen manuelle resettet werden. brick-flash-cmd-loetkolben2

Dass das Verify so viel schneller ist kann normal sein. Die Geschwindigkeit des Flashens variiert hier bei uns auch zwischen verschiedenen Rechner. Es sieht so aus als ob der Write und Verify Schritt durch sind bevor das Problem auftritt. Nach Write und Verify wird noch das Boot Flag Register des Mikrocontrollers von "Boot Loader" auf "Flash" gesetzt. Als Letztes wir der Brick über das Reset Register neugestartet. Ich vermute jetzt mal ins Blaue hinein, dass einer dieser beiden letzten Schritte das Problem verursacht, oder vielleicht auch das Verify. Warum und weshalb das passiert und ob das dann fixbar ist steht auf einem anderen Blatt. Um das Testen zu können habe ich dir eine erweitere Version vom brick-flash-cmd angehängt. Diese Version hat vier weitere Optionen. In diesem Beispiel werden all vier Schritte ausgelassen: ./brick-flash-cmd-loetkolben -p /dev/ttyACM0 -f brick_master_firmware_2_3_1.bin --no-write --no-verify --no-flag --no-restart Damit kannst du jetzt gezielt Schritte auslassen, um so vielleicht herauszufinden wo das Problem steckt. brick-flash-cmd-loetkolben

Derzeit ist da nichts in Planung. Aber mal als Denkanstoß: Wenn schon wechseln, warum dann Micro-USB? Warum dann nicht gleich USB Typ C nehmen?

RED Brick Image 1.6 Add Nagios for Starter Kit: Server Room Monitoring Add openHAB with Tinkerforge bindings Add missing DNS reverse lookup for wireless access point mode Enable kernel drivers for several Bluetooth dongles Set default HDMI fallback resolution to 800x480 Download: RED Brick Image

RED Brick Image 1.6 Nagios für Starterkit: Serverraum-Überwachung hinzugefügt openHAB mit Tinkerforge Bindings hinzugefügt Fehlendes DNS Reverse Lookup for WLAN Access Point Modus hinzugefügt Kernel Treiber für verschiedene Bluetooth Dongles hinzugefügt Standard HDMI Fallback Auflösung auf 800x480 gesetzt Download: RED Brick Image

Brick Viewer 2.2.3 Add server monitoring and openHAB configuration tabs to RED Brick plugin Restore DHCP IP address display for Ethernet Extension in Master Brick plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.2.3 Server Monitoring und openHAB Konfigurations-Tabs zum RED Brick Plugin hinzugefügt DHCP IP Adressanzeige für Ethernet Extension im Master Brick Plugin wiederhergestellt Downloads: Windows, Linux, Mac OS X

Was meinst du mit "das C# Programm wird gestoppt", stürzt es ab? Welche Fehlermeldung bekommst du?

If you installed apscheduler using pip, it'll probably be installed for Python2 only. Try installing it using pip3: sudo pip3 install apscheduler