photron

Ah, ich hatte es so verstanden, dass der Brick an sich noch funktioniert und die LEDs leuchten, er aber das System stört. Versuch den problematischen Master Brick noch mal in den Bootloader Modus zu versetzen. Dazu am besten den Master Brick von allem abstecken, den Erase Knopf drücken, mit gedrücktem Erase Knopf an USB anstecken und erst jetzt wieder den Erase Knopf loslassen. Wenn sich der Master Brick dann nicht flashen lässt dann - teste mal ein andere USB Kabel - einen anderen USB Anschluss am PC - schau dir alle 4 Bricklet Anschlüsse genau an, ob da nicht vielleicht Pins verbogen sind und Kurzschlüsse machen Eigentlich kann es aber ja nicht am PC oder am USB Kabel liegen, denn du konntest ja den Master Brick vorher updaten. Es liegt wahrscheinlich am Master Brick selbst.

Loetkolben, wie borg schon sagt kannst du dir das alles im brickd anschauen. Was du grob gesagt tun musst ist: - den Brick in der Liste der USB Devices finden - einen USB Handle für den Brick öffnen - Interface 0 claimen Dann kannst du Requests als Bulk Transfer an den Interface 0 OUT Endpoint senden und Responses als Bulk Transfer vom Interface 0 IN Endpoint empfangen. Die Pakete sind die gleichen die auch über TCP/IP versendet werden. Um mit USB zu interagieren kannst du z.B. libusb verwenden.

Okay, hier das Start-Program Beispiel in Java: http://www.tinkerforge.com/de/doc/Software/Bricks/RED_Brick_Java.html#start-program

Dass heißt, auf dem "kaputten" Master Brick ist Firmware 2.3.3 drauf? Was passiert wenn du die gleiche Firmware wie auf dem heilen Master Brick auf den "kaputten" flasht? Ältere Firmware Versionen kannst hier finden: http://download.tinkerforge.com/firmwares/bricks/master/ Im Brick Viewer dann "Custom" statt "Master" auswählen und die Firmware Datei angeben.

Hier ein Beispiel wie man ein Program auf dem RED Brick über die Python API startet: http://www.tinkerforge.com/en/doc/Software/Bricks/RED_Brick_Python.html#start-program Leider ist die Dokumentation der RED Brick API noch unvollständig und es gibt bisher nur dieses eine Python Beispiel.

Für eine neue Power Supply müssen wir erst noch mehr Forschung betreiben. Im Sinne von, welche Features soll sie wirklich haben und wie diese sinnvoll umgesetzt werden können. Wir haben schon einen ersten Prototypen entwickelt. Da das Thema aber komplex ist erfordert der Prototyp aufwändigere Langzeittests. Dazu sind wir aus Zeitgründen bisher noch nicht gekommen und die weitere Entwicklung liegt da gerade auch auf Eis. Einem OLED Display sind wir noch nicht weiter nachgegangen.

Der Brick Daemon leitet die Pakete unseres TCP/IP Protokolls unverändert durch und kümmert sich dabei um das Routing zwischen mehreren Bricks und mehreren TCP/IP Verbindungen. Du kannst also mit einem Brick auch direkt per USB sprechen und ihm die gleichen Pakete schicken, wie sie für unser TCP/IP Protokoll definiert sind: http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html Deutlich einfach ist es aber eine WIFI Extension zu verwenden. Dafür steckst du einen Master Brick unter den Servo Brick und eine WIFI Extension oben auf den Servo Brick. Dann kannst du die WIFI Extension als Access Point konfigurieren, dich vom Smartphone aus damit verbinden und dein bisheriges Steuerprogramm für die Schlange weiterverwenden.

Das ist eine Variante dieses Problems: http://www.tinkerunity.org/forum/index.php/topic,3132.0.html Es liegt an der Master Brick Firmware 2.3.2. Wir arbeit gerade an einer Lösung. Bis dahin kannst du das Problem umgehen indem du Master Brick Firmware 2.3.1 verwendest.

See brickd.log on the RED Brick: http://www.tinkerforge.com/en/doc/Hardware/Bricks/RED_Brick.html#system-logs

As also stated in the documentation that borg mentioned, you need to add ws2_32.lib and advapi32.lib as additional dependencies to the Visual Studio project.

Welche Baudrate hast du bei den RS485 Extensions eingestellt? Der RED Brick unterstütz die hohen Baudrate über 500 kBaud nicht: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick.html#rs485-extension

Bei einem früheren Refactoring des Upload Dialogs war ein unnötiger open() Aufruf stehen geblieben. Dadurch wurde jede Datei zweimal geöffnet aber nur einmal geschlossen. Bedingt durch die Art und Weise wie Qt Creator Dateien schreibt kann dieser geöffnete Dateien nicht überschreiben. Das Problem ist jetzt im git behoben. Danke für den Hinweis!

Das kann ich hier reproduzieren auf Windows. Allerdings scheint es auch mit der Art und Weise zusammenzuhängen, wie Qt Creator die Datei schreibt, denn z.B. mit Notepad kann ich eine zuvor hochgeladene Datei ohne Probleme ändern.

Das ist ein Bug in Brick Viewer 2.2.4. In der gerade veröffentlichten Version 2.2.5 ist das Problem behoben.

Brick Viewer 2.2.5 Add support for IMU Brick 2.0, Accelerometer, Ambient Light 2.0, Analog In 2.0, Analog Out 2.0, Dust Detector, Industrial Analog Out, Industrial Dual Analog In, Laser Range Finder, Load Cell and RS232 Bricklet Fix callback handling in GPS Bricket plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.2.5 Unterstützung für IMU Brick 2.0, Accelerometer, Ambient Light 2.0, Analog In 2.0, Analog Out 2.0, Dust Detector, Industrial Analog Out, Industrial Dual Analog In, Laser Range Finder, Load Cell und RS232 Bricklet hinzugefügt Callback-Behandlung im GPS Bricket Plugin korrigiert Downloads: Windows, Linux, Mac OS X

Alle Bricklets haben ein EEPROM in dem die UID und das Firmware Plugin für das jeweilige Bricklet stehen. Das EEPROM ist per I2C angeschlossen und Bricks lesen beim Start alle EEPROMs der angeschlossenen Bricklets aus. Ein Teil der Bricklets verwenden I2C Sensoren oder Aktoren, diese hängen am gleichen I2C Bus wie das EEPROM des Bricklets. Der Master des Stapels kommuniziert mit allen anderen Bricks im Stapel per SPI. Es gibt in den Stack Steckern zwei Pins zur Erkennung welcher der Master Bricks im Stack der unterste ist: Stack-High im oberen Stecker und Stack-Master-Detect im unteren Stecker. Beim Start setzt jeder Master Brick seinen Stack-High Pin auf High, wartet einen Moment und schaut dann seinen Stack-Master-Detect Pin an. Wenn er dort auch High sieht, dann ist noch ein Master Brick unter ihm ist, er ist also nicht Master des Stacks. Wenn er Low auf Stack-Master-Detect sieht, dann ist er Master des Stacks.

Sorry, hab den Thread wohl übersehen, war keine Absicht. Ich hab das besagte Python Skript gerade noch einmal getestet und es funktioniert exakt wie erwartet. Ich habe folgendes getan: - IMU flach auf den Tisch gelegt, alle LEDs zeigen nach oben. - Erst jetzt starte ich das Skript, damit diese Position die Null-Position wird. - Wenn ich jetzt die IMU flach auf dem Tisch liegend um 45° um die Z Achse (die senkrechte Achse) drehe, dann wird auch 45° für Z angezeigt.

Das Spalte/Reihe vertauscht erscheint ist richtig. Die LED Matrix wird im Programm hochkant adressiert, die Schrift aber auf der Seite liegend angezeigt. Das Beispiel verwendet eine fest 7x7 Pixel Schriftart die im letterForms Array definiert ist. Wenn deine Matrix nicht die ausreichende Höhe hat wird der Text abgeschnitten angezeigt. Du könntest deine Matrix zu 7x7 umbauen und im Beispiel den Versatz um eine Spalte nach links (bzw. eine Zeile nach unten) auf 0 setzen. Dazu $this->leds[$row][$col + 1] durch $this->leds[$row][$col] ersetzen.

BOBmoraine, betrifft es immer den rechten Stack in deinem Bilder, der rot umrandet ist? Da könnte die Lage, bzw. die Nähe zu anderen Bauteilen wie dem Netzteil ein Problem sein. tfRookie, wie schaltet du denn diesen Motor? Über Tinkerforge Komponenten? Wie nah ist der Stack am Motor, bzw. gehen die Motorstromkabel nah am Stack entlang? Auch wenn der Stack nichts mit dem Motor direkt zutun hat kann der Motor den Stack elektromagnetisch stören. Zum Beispiel durch das parallele Verlegen von Bricklet/USB Leitungen und 230V Leitungen, wie batti schon sagt. Was du testen könntest ist den Stack abzuschirmen z.B. durch ein metallisches Gehäuse. Bricks und Bricklets sind hier potentiell etwas anfälliger, da sie kein Gehäuse haben. Das Log beinhaltet viele und auch ungewöhnliche USB Fehler. Zum Beispiel, diese beiden sind mir noch nie untergekommen: Das sieht für mich fast so aus als ob irgendein Teil des USB Systems gestört wird. Ob das die Brick Seite oder PC Seite betrifft ist nicht klar.

Die RS485 Extension ist für die Kommunikation zwischen zwei Stacks gedacht. Sie ist nicht dafür gedacht externen Geräte anzusprechen. Im Gegensatz dazu ist das RS232 Bricklet genau dafür gedacht externe Geräte anzusprechen.

Und da sehe ich das Problem auch schon. Ein Bauteil auf der Unterseite sitzt nicht da wo es hingehört. Ich hab es mal mit einem Pfeil markiert. Das Bauteil gehört eigentlich 2mm weiter nach links auf die 4 kleinen Anschlüsse. Das ist eine Spule die in den USB Datenleitungen sitzt. Der Brick bekommt jetzt zwar noch Strom über USB, aber die Datenkommunikation ist tot. Passt exakt zum beschriebenen Problem. Da der Brick geflasht war, muss er noch heile gewesen sein bevor wir ihn verschickt haben und er hat dann den Transport nicht überlebt, sorry. Melde dich mit deiner Bestellnummer und einem Verweis auf diesen Thread hier bei info@tinkerforge.com. Du bekommst einen neuen Master Brick.

Leuchten die vier LEDs an der Seite wirklich nur jeweils einmal auf? Normalerweise sollten die LEDs wie ein Lauflicht mehrfach hin und her laufen und zwischen drin auch einmal kurz alle gleichzeitig an sein. Da ein anderes Kabel/PC nicht hilft ist das Problem wohl auf der Master Brick Seite. Versuch mal die Firmware des Master Bricks neuzuflashen: http://www.tinkerforge.com/de/doc/Software/Brickv.html#mit-brick-viewer

Leuchten den beim Anstecken an USB oder nach dem Drücken des Reset Knopfs am Brick die vier anderen blauen LEDs auf? Hast du mal ein anderes USB kabel oder einen anderen USB Anschluss am PC probiert? Hast du am Master Brick irgendwelche Bricklets angeschlossen? Wenn ja, taucht der Master Brick auf, wenn keine Bricklets angeschlossen sind?

Was ihr beide mal testen könnte ist eine neue Firmware für den Master Brick: master-brick-2.3.2-beta2.bin Die an diesem Post angehängt ist: http://www.tinkerunity.org/forum/index.php/topic,2580.msg18819.html#msg18819 Da ist die USB Logik abgewandelt. Das könnte hier relevant sein.