photron

Okay, it seems that we were using the config parser is a wrong way. I wonder why this worked before. Anyway, this change in config_parser.py will be part of the next brickv version. Thanks for reporting this problem.

Funktioniert es wenn du RS485 statt USB nimmst und das Barometer Bricklet alleine ist? Sprich was musst du verwenden, damit das Problem auftritt? Muss ein anderes Bricklet mit am Master Brick sein, oder musst du den Master Brick über RS485 anschließen?

No, forget about that. Replace the whole brickv-2.3.4/src/brickv/plugin_system/plugins/red/config_parser.py file with the attached version. config_parser.py

Strange, something funny is going on there. Please try to replace this try: import configparser except: import ConfigParser as configparser # Python 2 fallback in brickv-2.3.4/src/brickv/plugin_system/plugins/red/config_parser.py with this try: import ConfigParser as configparser except: import configparser # Python 3

Wenn das Barometer Bricklet alleine war und funktioniert hat, hattest du dann den Master Brick über RS485 oder über USB angeschlossen?

hardillb, that traceback is unexpected. It seems that self.network_all_data['manager_settings'] has a wrong type. What Python version are you using? Could you add print self.network_all_data['manager_settings'] in front of the iname_previous = self.network_all_data['manager_settings'].get('Settings', 'wired_interface', '') line in red_tab_settings_network.py, then restart Brick Viewer and click the connect button again. It should print something like this: <ConfigParser.ConfigParser instance at 0x7fdaaf8fcdd0>

foley, das Problem tritt also nicht auf, wenn das Bricklet alleine an einem Master Brick hängt. Tritt das Problem den jetzt wieder auf, wenn du den Aufbau zurückbaust auf den Stand als das Problem auftrat? Wenn ja, was hast du dann noch am Master Brick neben dem Barometer Bricklet angeschlossen, das vielleicht das Problem auslöst?

Was tut den dein Programm? Tritt das Problem auch auf, wenn du eines unserer Java Beispiele nimmst?

Im Pixel Matrix Beispiel wird eine bool Matrix erzeugt (pixel_matrix) die die Größe des Displays hat. Jeder bool Wert stellt ein Pixel da. Wenn du jetzt Pixel y=10 und x=20 setzen willst dann musst pixel_matrix(10, 20) = true setzen. Die draw_matrix Funktion kümmert sich dann darum die pixel_matrix anzuzeigen. Momentan kann das Beispiel nur den ganzen Display überschreiben. Es steht auf der TODO Liste den Beispielen auch beizubringen nur Teile des Displays überschreiben zu können.

Laut Debian Jessie Package Repository hängt das Mosquitto Package nicht vom libwebsocket Package ab. Daher denke ich das Mosquitto ohne WebSocket Support gebaut ist. Hier gibts eine (ungetestete) Anleitung wie das selbst ändern kannst: http://www.xappsoftware.com/wordpress/2015/05/18/six-steps-to-install-mosquitto-1-4-2-with-websockets-on-debian-wheezy/

Sprünge um mehrere mbar innerhalb von Sekunden ist nicht normal. Wie ist dein Stapel aufgebaut? Wie lang ist das Bricklet Kabel zum Barometer Bricklet? Was ist noch am gleichen Brick mit dem Barometer Bricklet angeschlossen? Was passiert, wenn du das Bricklet alleine an einen Brick anschließt?

Sehr gut! Neue Version ist veröffentlicht. Danke für den Hinweis auf das Problem.

Plugin: IO-16 Bricklet 2.0.6 Fix edge count pin direction check for pin A2 Fix race condition in interrupt detection that resulted in missed interrupts Download: IO-16 Bricklet

Plugin: IO-16 Bricklet 2.0.6 Flankenzählerrichtungs-Check für Pin A2 korrigiert Race Condition in der Interrupt-Erkennung, der zu verpassenten Interrupts führen konnte, korrigiert Download: IO-16 Bricklet

Okay, das Problem war eine Race Condition in der Erkennung von Interrupts. Hier eine korrigierte Firmware für dich zum Testen. Danke für das Lob! Momentan gibt es aber keine Pläne eine Niederlassung in der Schweiz. io16-bricklet-206-rc1.bin

Wie hast du denn den RED Brick netzwerkmässig mit dem PC verbunden? Abhängig davon muss du natürlich die statische IP Adresse passend konfigurieren. Du kannst da nicht einfach irgendwas einstellen, dass muss schon zum Rest des Netzwerks passen, sonst funktioniert das Routing nicht. Das ist kein Problem mit dem RED Brick, sondern ein grundsätzliches Sache der Netzwerkkonfiguration.

Ich habe das mal gerade nachgebaut und kann das Problem nachstellen. Irgendwo ist das ein Bug, sorry. Ich kümmere mich drum.

Genau das. Potentiell kannst du das wahrscheinlich verlängern, getestet haben wir das aber nicht. Das wird aber auch daran scheitern ein passendes UF.L Stecker nach UF.L Buchse Verlängerungskabel zu bekommen.

Die Ethernet Extension steckst du auf den Stapel und schließt dann den Stapel nochmal an USB an, damit du die Ethernet Extension im Brick Viewer konfigurieren kannst. Die Einstellungen befinden sich auf dem Tab des untersten Master Bricks im Stapel. Dort kannst du jetzt zwischen DHCP und statischer IP Adresse wählen und auch einen Hostnamen festlegen. Nach dem Speichern der Einstellungen, den Stapel neustarten und das Ethernet Kabel anschließen, falls noch nicht gesehen. Du kannst jetzt die USB Verbindung durch ein USB Netzteil ersetzen, oder eine Step-Down Power Supply verwenden, oder eine Ethernet Extension mit PoE, falls du PoE verwenden kannst/willst. In deinem Programm ersetzt du jetzt "localhost" durch die IP Adresse oder den Hostnamen der Ethernet Extension. Der Rest bleibt gleich.

Brick Viewer benutzt keine konfigurierbaren Callbacks, wie den Interrupt Calback, mehr. Das hat zu viele Probleme gemacht, wenn Brick Viewer und ein anderes Programm gleichzeitig Callback konfiguriert haben. Weil dann das andere Programm möglicherweise nur dann richtig funktioniert wenn Brick Viewer auch läuft und den richtigen Tab auf hat. Um diese Verwirrung zu vermeiden, pollt Brick Viewer z.B. die IO-16 mit 20Hz. 5-10% sind sehr viel. Da würde ich viele Timeouts im Brick Viewer erwarten, wenn wirklich 5-10% der Nachrichten verloren gingen.

Das Achsen-Remapping ist nicht über die API des IMU Bricks zugänglich. Es würde dir aber auch nicht erlauben das Koordinatensystem um beliebige Winkel zu drehen, sondern nur Achsen zu vertauschen. Das einfachst ist du speicherst dir zu Begin den Yaw-Winkel und subtrahierst diesen Wert dann im laufenden Betrieb vom aktuellen Yaw-Winkel. Dadurch bekommst du dann einen Yaw-Winkel beim dem 0° der Ausgangsposition entspricht.

Die Beispiele arbeiten immer nur mit "LAN" weil es in dem Sinne nur "LAN" (TCP/IP) gibt. Der Brick Daemon kümmert sich um die Umsetzung zwischen TCP/IP und USB. Sprich alle LabVIEW Beispiel verbinden sich standardmäßig zu localhost auf Port 4223. Dort lauscht der Brick Daemon und macht dir die Bricks an USB zugänglich.

Dafür gibt es so direkt keine Funktion. Dein Vorgehen ist aber schon genau das richtige.

Dein Programm wird nicht in einem Terminal, sondern auf dem RED Brick im Hintergrund ausgeführt. Daher bekommst du keine Tastatureingaben. Hier wird beschrieben, wie man in C dennoch an die Tastatureingaben kommt: http://unix.stackexchange.com/questions/94322/is-it-possible-for-a-daemon-i-e-background-process-to-look-for-key-presses-fr Alternativ gibst du deinem Programm ein GUI um so an die Tastatureingaben zu kommen. Ich setze mir mal auf die TODO Liste mir anzuschauen wie viel Aufwand es wäre dem RED Brick beizubringen Tastatureingaben an ein Programm weiter zu leiten.

Es liegt aber nicht das Mini USB Kabel, oder? Sprich der eine Brick funktioniert am gleichen Kabel an dem der andere nicht funktioniert? Wenn das so ist, dann melde dich bitte mit Hinweis auf diesen Thread bei info@tinkerforge.com. Wir tauschen den defekten Master Brick aus.