photron

Standa hat recht die Geräusch sind unbedenklich, wohl aber unschön. Du könntest im Stillstand einfach den Stepper Brick disablen. Wenn das in deinem Fall nicht möglich ist, weil der Motor aktive eine Position halten muss dann kannst du versuchen den Decay Modus passender zu deinem Motor einzustellen. Standardmässig wird Fast Decay verwendet, das ist die sichere Variante. Es gibt im Brick Viewer keinen Regler für den Decay Modus da es bei großen Motoren bei "falschem" Decay Modus zur Überhitzung und Zerstörung des Bricks kommen kann. Mit 1,2A hast du da aber einen Motor bei dem du ohne Problem mit dem Decay Modus experimentieren können solltest. Dazu musst du dann allerdings dann dein eigenen Programm schreiben und über die SetSyncRect Funktion des Stepper Bricks die Synchrongleichrichtung aktivieren und kannst dann über SetDecay zwischen Fast, Mixed und Slow Decay einstellen.

Es gibt Hot, Warm, Cold und Full Cold Start. Je kälter desto weniger zwischengespeicherte Daten wie die Satellitenflugbahnen und die Uhrzeit werden nach dem Neustart wiederverwendet. Mit Enums für Magicnumbers geb ich dir recht und setzte es mal auf die TODO Liste. Dass get_date_time ein DateTime-Objekt zurück gibt wird allerdings nicht passieren in absehbarer Zeit. Da ist das Feld der Möglichkeiten einfach zu groß als das man das im Generator sinnvoll unterbringen könnte.

Wir haben noch mal das GPS Modul gewechselt. Das neue Modul bekommen wir dann auch mit einem Binärprotokoll, das einfacher zu parsen ist. Dadurch ist jetzt auch wieder Platz freigeworden und wir könne GetStatus aufteilen, wie das hier schon vorgeschlagen wurde. Die aktuelle API ist hier zu finden: http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html Neben der Aufteilung von GetStatus gibt jetzt GetCoordinates auch den Estimated Position Error (EPE) zurück.

skippi, dass brickd Problem haben kann wenn ihm der RAM ausgeht kann ich verstehen. Warum da aber irgendwie das Neuflashen von Bricks einen Effekt haben soll sehe ich nicht.

Hast du denn das Bricklet neugeflashed?

Alle Bricklets funktionieren an allen Ports aller Bricks. Da gibt es keine Einschränkungen. Da das Problem hier durch neu Flashen des IO-4 Bricklets gefixed wurde, würde ich vermuten, dass das im EEPROM des Bricklets gespeicherte Plugin eine Macke hatte. Das würde auch erklären, warum das Problem an 2 Master Bricks auftrat. Warum es dann nur am Master Brick und dann auch noch von Port und der Extension Konfiguration abhängt ist nicht klar. WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere Firmware verwendet?

Die Kalibrierung für den Sensor wird im EEPROM auf dem Bricklet gespeichert. Die kannst du mittels Brick Viewer ändern, siehe: http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung-speichern

Die MSDN Knowledge Base sagt, dass Windows 8 und Windows 7 (seit Mai 2012) automatisch den passenden Treiber installieren können, wenn ich das USB Gerät korrekt als WinUSB kompatible ausgibt. Wir verwenden WinUSB über libusb, daher sollte das gehen. Ich habe das testweise funktioniert und der Brick sollte sich jetzt als WinUSB kompatible ausgeben können. Leider funktioniert das noch nicht so richtig wie es soll. Bis dahin kann ich dir den WinUSB Driver Installer Zadig von den libsub Entwicklern als Lösung anbieten. Dieser kann unter Windows 8 einen passenden und signierten Treiber installieren. http://download.tinkerforge.com/_stuff/zadig_v2.0.1.159.exe Wenn du das startest sollte das etwa so aussehen: Wichtig ist dabei, dass das richtige Device ausgewählt ist (hier 'Master Brick') und WinUSB als Treiber. Dann 'Install Driver' klicken. Möglicherweise musst du dann noch einmal den Brick ab und wieder anstecken, damit er dann erkannt wird.

Ich kann das Problem hier reproduzieren. Eine Lösung ist in Arbeit.

Das ist eine sinnvolle Idee. Ich habe dazu gerade den ersten Schritt getan und alle Funktionen in den Configs mit ihrer "minimumRequiredFirmwareVersion" versehen. Als nächsten kommen, dann Checks dafür in den Bindings.

Sollte jetzt funktionieren.

Der Zeichensatz des LCDs ist fest und damit auch die Ausrichtung der Zeichen. Es ist daher rein technisch nicht möglich die Zeichen auf den Kopf zu drehen.

1. Nein, das geht nicht. 2. Ich nehme mal an du machst das im Moment so oder so ähnlich: lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y); Da die Darstellung von x maximal 4 Zeichen (-100) bis 1 Zeichen (0) lang sein kann, musst du nur 3 extra Leerzeichen anhängen um bei x = 0 die restlichen 3 Zeichen zu "löschen". Da ich hier x und y in einer Zeile habe macht das 6 Leerzeichen, also: lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y + " "); 3. Du musst einfach durch 10.0 (float) statt durch 10 (int) teilen: lcd.WriteLine(0, 0, "Temperature: " + t / 10.0);

Brick Daemon 1.0.10 Enable non-root usage on Linux Avoid potential data corruption in python-libusb1 Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.10 Kann jetzt als nicht-root User unter Linux gestartet werden Mögliche Datenkorruption in python-libusb1 vermieden Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.13 Switch from green to dark green in graphs for better contrast on gray Show Barometer Bricklet altitude also in feet Fix progress dialog for Bricklet flashing Handle old names for Temperature IR and Distance IR Bricklets in Check-for-Updates dialog Automatically restore IMU factory calibration after flashing Improve flashing verification speed by reading whole flash pages Improve progress dialog for firmware and plugin discovery in flashing window Add basic FreeBSD support Add button to restore factory calibration to IMU calibration window Add missing image for Dual Replay Bricklet plugin Downloads: Windows, Linux, Max OS X

Brick Viewer 1.1.13 Grün durch Dunkelgrün in Graphen ersetzt Barometer Bricklet Höhe wird nun auch in Fuß angezeigt Fortschrittsanzeige beim Flashen von Bricklets verbessert Alte Namesversionen des Temperature IR und Distance IR Bricklets beim Check-for-Updates werden richtig behandelt IMU Werkskalibrierung kann nach dem Flashen automatisch wiederhergestellt werden Geschwindigkeit des Verifikationsschritts beim Flashen beschleunigt Fortschrittsanzeige bei der Abfrage der verfügbaren Firmware und Plugin Versionen verbessert Grundlegende FreeBSD Unterstützung Knopf zum automatischen Wiederherstellen der Werkskalibrierung zum IMU Kalibrierungsfenster hinzugefügt Fehlendes Bild zum Dual Replay Bricklet Plugin hinzugefügt Downloads: Windows, Linux, Max OS X

Bindings: C/C++ 1.0.23, C# 1.1.15, Delphi 1.0.7, Java 1.0.21, PHP 1.0.16, Python 1.0.24, Ruby 1.0.13 Add get_usb_voltage function to Master Brick API [All] Add Barometer Bricklet examples [All] Handle difference between currentThread and current_thread to support Python 2.5 [Python] Changed callback_queue from class variable to instance variable [Python] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 1.0.23, C# 1.1.15, Delphi 1.0.7, Java 1.0.21, PHP 1.0.16, Python 1.0.24, Ruby 1.0.13 get_usb_voltage Funktion zur Master Brick API hinzugefügt [Alle] Barometer Bricklet Beispiele hinzugefügt [Alle] Unterschied zwischen currentThread and current_thread wird richtig behandelt um Python 2.5 zu unterstützen [Python] callback_queue der IPConnection von Klassenvariable zu Instanzvariable geändert [Python] Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Das ist komisch. Genau da hätte ich jetzt auch Probleme erwartet. Andere Frage: Wie lang sind die Bricklet Kabel die du da verwendest? Falls dem noch nicht so ist, kannst du dann mal den originalen Aufbau mit 15cm Kabel testen, oder dem kürzesten was du zur Hand hast?

Jetzt wo du's sagst kann ich das bestätigen. Bie mir sind es etwa 0,3°C weniger. Ich hatte vor Version 1.1.2 noch eine Abweichung in der implementierten Berechnung im Vergleich zu der im Datenblatt beschriebenen. Diese habe ich in Version 1.1.2 korrigiert.

Also die Vermutung ist, dass es ein Problem mit der I2C Kommunikation ist und sich das Temperatur IR und das Barometer da in die Quere kommen. Möglich wäre dass dein Temperatur IR Bricklet ein Problem hat und dem Barometer Bricklet reinredet. Hast du noch andere I2C Bricklets zur Hand? Z.B. ein Temperatur Bricklet, ein LCD Bricklet oder ein IO-16 Bricklet? Interessant sind jetzt ob bei folgenden Kombinationen jeweils alle Bricklets richtig funktionieren: Barometer Bricklet mit einem der anderen I2C Bricklets Temperatur IR Bricklet mit einem der anderen I2C Bricklets

Wie da konstant 20°C bei raus kommen können ist mir nicht klar. Ich habe jetzt erstmal Version 1.1.2 released, die arminiusdcs Sprungproblem im Zusammenhang mit dem LCD behebt. Du scheinst da noch ein anderes Problem zu haben. Ich experimentiere gerade noch mit ein paar Dingen in diese Richtung.

Barometer Bricklet Plugin 1.1.2 Fix sensor readout timings, avoids reading wrong sensor values Download: Plugin

Barometer Bricklet Plugin 1.1.2 Timing für das Auslesen des Sensors korrigiert, vermeidet das Lesen falscher Sensorwerte Download: Plugin