photron

Das ist ein Bug in der IMU Firmware, der in Version 2.0.1 behoben wurde. Der Button heißt "Auto-Update all Bricklets". Bricks können nicht automatisch aktualisiert werden. Das musst du von Hand machen, siehe: http://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-viewer

I'm afraid that you're out of luck. From the xrandr output its seems that the RED Brick video driver doesn't support rotation, sorry

Das wurde halb vergessen und halb verzögert für WIFI Extension 2.0. Neue WIFI Extension und Real-Time Clock Update kommt aber diese Woche. Sorry für die Verzögerung!

From where did you ran xrandr? Maybe you need to specify DISPLAY=:0? DISPLAY=:0 xrandr

Your IMU Brick is in bootloader mode now, due to the button press. You need to flash it again, see: http://www.tinkerforge.com/en/doc/Software/Brickv.html#using-brick-viewer About the "leak": the beige component is a ceramic capacitor that has nothing inside it that could leak. Can you wipe off the "leaked" stuff?

Das sollte genau so funktionieren. Macht es einen Unterschied, wenn du den Master Brick alleine an USB anschließt, also ohne Bricklets? Wenn du den Master Brick an USB ansteckst, zeigen dann die 4 LEDs an der Seite kurz ein Lauflicht?

Ich hätte jetzt sagen wollen: Du musst doch nur Brickv ein zweites mal starten. Scheint leider unter OS X nicht so einfach zu sein. Das Internet sagt open -n /Applications/Brickv.app sollte funktionieren. Brickv versteckt denn Data Logger nicht selbst, das macht OS X von sich aus. Muss ich mir ansehen, ob wir das verbessern können.

Sehr komisch. Tritt denn das Problem bei dir auch nur in Zusammenhang mit RS485 auf, oder tritt das Problem auch auf, wenn das Bricklet alleine an einem Master Brick über USB angeschlossen ist?

Wenn diese SAP Bibliothek wirklich x86 Native Code enthält, dann wird dir C++ nicht helfen, weil du auf dem ARM CPU des RED Bricks keine x86 Code ausführen kannst. Ich denke du brauchst diese SAP Bibliothek kompiliert für ARM.

Ich denke das Problem ist folgendes: Da diese SAP DLL auf Windows funktioniert wird dessen Native Code für x86 kompiliert sein. Der Fehler besagt jetzt, dass Mono auf dem RED Brick den x86 Native Code nicht ausführen kann, da der RED Brick nicht x86 sondern ARM ist. Ich würde vermuten, dass es funktioniert wenn du dieses SAP DLL für ARM kompiliert hättet. Wenn ich das hier lese, dann denke ich, dass du da ein Mixed-Mode Assembly, hast und das unterstütz Mono wohl auf Linux noch nicht. http://www.mono-project.com/docs/about-mono/languages/cplusplus/

Wenn das Bricklet flach auf dem Tisch liegt, solltest du 1g in Z Richtung sehen und X, Y sollten nahe 0g sein. Das zeigt der Brick Viewer Screenshot ja auch an. Dein Problem ist jetzt, dass dein Programm bei der gleichen Lage des Bricklets für die Y Richtung 1g anzeigt, anstatt in Z Richtung? Also Brick Viewer und dein Programm nicht die gleichen Werte bei der gleichen Lage des Bricklets anzeigen? Hast du mal dieses Beispiel ausprobiert? http://www.tinkerforge.com/de/doc/Software/Bricklets/Accelerometer_Bricklet_VBNET.html#simple Du schaust dir aber auch das gleiche Bricklet an? Nicht das du zwei Accelerometer Bricklets angeschlossen hast und Brick Viewer und dein Programm das jeweils andere anzeigen. Übrigens zeigt dein Programm die g Werte als m/s^2 an, aber 1g sind 9,80665 m/s^2.

Malik, bist du sicher, dass du die neue Firmware richtig geflasht und den Stack danach neugestartet hast? Zeigt Brick Viewer für das Bricklet 2.0.3 an? Denn eigentlich sollte das Problem in 2.0.3 behoben sein. Ich konnte es vorher reproduzieren und mit 2.0.3 dann nicht mehr. Alternativ tritt bei dir noch ein anderes Problem auf, dass 2.0.3 noch nicht behebt.

TVPL ist eine visuelle Programmierumgebung um Tinkerforge Bricks und Bricklets zu steuern. TVPL basiert auf Googles Blockly. Eine TVPL Alpha Version kann lokal ausprobiert werden (source/index.html im angehängten ZIP) oder von unserem Server (empfohlen) aus unter: http://tvplalpha.tinkerforge.com/ Momentan können von Brick und Bricklets Getter/Setter genutzt werden und mit Buttons, Labels und Plots GUIs gebaut werden. Beispiel und readme-alpha.txt mit mehr Details finden sich im angehängten ZIP. TVPL Programme können momentan nur direkt im Browser ausgeführt werden. Wir hätten gerne eure Meinung dazu gehört. Gefällt euch das? Haltet ihr das für sinnvoll? Was gefällt euch daran nicht? usw. tinkerforge_tvpl_bindings_2_0_0_alpha.zip

TVPL is a visuell programming environment to control Tinkerforge Bricks and Bricklets. TVPL is based on Google's Blockly. A TVPL alpha version can be tested locally (source/index.html in the attached ZIP file) or on our server (recommended): http://tvplalpha.tinkerforge.com/ At the moment getters/setters of Bricks and Bricklets can be used und buttons, labels and plots can be used to form GUIs. Examples and a readme-alpha.txt with more details can be found in the attached ZIP file. TVPL programs can currently be executed in the browser only. We'd like to hear your feedback about TVPL. Do you like it? Do you think it's useful? What don't you like about it? etc. tinkerforge_tvpl_bindings_2_0_0_alpha.zip

foley und Malik, testet doch mal die angehängt Version der Barometer Bricklet Firmware. barometer-bricklet-203-test1.bin

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/