photron

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/

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.