borg

Firmwares: DC Brick 2.3.6, IMU Brick 2.3.6, IMU 2.0 Brick 2.0.11, Master Brick 2.4.7, Servo Brick 2.3.6, Silent Stepper Brick 2.0.5, Stepper Brick 2.3.7 Fix für Nachrichtenduplizierungs-Bug Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Firmwares: DC Brick 2.3.6, IMU Brick 2.3.6, IMU 2.0 Brick 2.0.11, Master Brick 2.4.7, Servo Brick 2.3.6, Silent Stepper Brick 2.0.5, Stepper Brick 2.3.7 Fix message duplication bug Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Die API funktioniert bei mir, getestet mit import com.tinkerforge.IPConnection; import com.tinkerforge.BrickMaster; public class ExampleStackStatus { private static final String HOST = "localhost"; private static final int PORT = 4223; private static final String UID = "68z3jd"; // <------ CHANGE TO YOUR UID public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); BrickMaster master = new BrickMaster(UID, ipcon); ipcon.connect(HOST, PORT); master.disableWifi2StatusLED(); ipcon.disconnect(); } }

Die API sollte natürlich funktionieren, muss ich gleich ausprobieren. Bei der letzten Bestückung ist die LED in der Tat sehr hell ausgefallen, obwohl wir soweit ich das verstehe weder LED noch Vorwiderstand gewechselt haben und wir betreiben die LEDs bereit unterhalb des spezifizierten Stroms damit sie nicht so hell ist .

Ich meinte die "set_sensor_fusion_mode" Funktion. Damit kann man einen Fusion-Modus ohne Magnetometer auswählen, dann kann es nicht mehr zu Drift auf Grund von Magnetfeldern kommen. Allerdings kann die IMU dann keine absoluten Werte mehr zurück geben sondern nur noch Veränderungen (ob das für eure Anwendung OK ist weiß ich nicht). Dass das drei Vergleichswerte sind hab ich mir schon gedacht. Bei ~1200 Sekunden sieht es so aus als würden die IMU Brick Daten zurückspringen auf die anderen Daten. Die Frage ist warum das passiert dort?

Ein Drift kommt oft Zustande wenn sich Magnetfelder in der Umgebung ändern. Welchen "Sensor Fusion Mode" verwendet ihr? Gibt es irgendein spezielles Event bei ~1200 Sekunden welches dazu geführt hat das der Wert zurückspringt?

Um per UART zu flashen ist das nicht passend angeschlossen. Macht auch keinen Sinn, dann könnte man per WIFI flashen, aber nicht per Ethernet. Das versteht dann am ende des Tages niemand mehr was da funktioniert und was nicht . Die Vorgehensweise wäre denke ich in der Tat "einfach" über unser normales Protokoll zu flashen, wie wir es auch bei den neuen Bricklets machen. Die einfachste Möglichkeit das zu implementieren ist sicherlich 50% des Flashes nur zum flashen zu nutzen (um dort Zwischenspeichern zu können). Ein unveränderlicher Bootloader der aber trotzdem Ethernet/WIFI/RS485 sprechen kann (damit auch auch darüber flashen kann) ist leider sehr viel Aufwand. 50% flash haben wir leider nicht frei bei allen Bricks. Blöd ist es auch wenn man dann doch einmal etwas am Ethernet/WIFI/USB Code ändern muss. Dann muss man auf einmal doch wieder über den Atmel-Bootloader flashen. Das macht es dann natürlich komplizierter .

Konnte das gerade doch kurz testen und bei mir funktioniert alles so wie es soll. Habe den Brick Viewer gestartet und dann folgendes ausgeführt: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "D1H" # Change XYZ to the UID of your Thermal Imaging Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_thermal_imaging import BrickletThermalImaging # Callback function for high contrast image callback def cb_high_contrast_image(image): print("cb") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection ti = BrickletThermalImaging(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Register high contrast image callback to function cb_high_contrast_image ti.register_callback(ti.CALLBACK_HIGH_CONTRAST_IMAGE, cb_high_contrast_image) # Enable high contrast image transfer for callback ti.set_image_transfer_config(ti.IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE) raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() Der Brick Viewer nutzt das High Contrast Image im Callback-Modus. Wenn ich die "set_image_transfer_config"-Funktion auskomentiere und das Skript ausführe läuft im Brick Viewer alles weiter und ich bekomme "cb" Prints über den Callback (welcher vom Brick Viewer gestartet wurde). Wenn ich die Funktion drin lasse und dadurch die Config auf "manual" umstelle bleibt das Bild im Brick Viewer stehen und ich bekomme auch keine Prints. Die LED hört auch auf zu blinken.

Ja gehört es. Du verwendest auch RS485? Dann ist das Update wahrscheinlich wirklich der Grund für die Verbesserung .

Das Flashen der Bricks läuft über den internen USB Bootloader (der ist in Hardware) der SAM3S/SAM4S Prozessoren. Das hat den großen Vorteil das man Bricks nicht komplett "bricken" kann, da man über den Erase-Knopf immer in den USB-Bootloader kommt. Das funktioniert auch noch wenn ich ausversehen eine mp3-Datei anstatt einer Firmware flashe . Hat aber den Nachteil das wir da nichts dran ändern können. D.h. das Flashen geht nur über USB wenn der Brick im Bootloader-Modus ist.

Huch? Das muss ich testen, du solltest keine Callbacks mehr bekommen wenn du auf "manual" umstellst. Komme ich aber frühestens Montag zu.

Dein PC benötigt kein WLAN, die Extension sollte auf jeden Fall im Brick Viewer auftauchen wenn du sie auf den Master Brick steckst und diesen per USB mit dem PC verbindest. Da die LEDs der WIFI Extension blinken läuft dort zumindest auch die Firmware. Bitte melde dich mit der Bestellnummer bei info@tinkerforge.com, wir schicken einen neuen Master Brick und eine neue WIFI Extension 2.0 raus (es ist unklar wer von den beiden hier Schuldig ist).

Von den Bricks? Da gibt es aktuell keine API für, geht also nur per Knopf.

Um den Aufbau zu verkleinern, kannst du mal einmal nur Master Brick + WIFI Extension anschließen? Taucht die Extension dann auf?

Das hatte uns erst selbst ein wenig durcheinander gebracht. Die Spezifikation von Flir gilt für den kleinen Bereich (-10°C bis 140°C/450°C). Die API läuft über den kompletten uint16 Bereich mit der 0,1°/0,01°C Auflösung. D.h. bei Temperaturen über 140°C solltest du bereits in den 0,1°C-Auflösung Modus wechseln. Im Brick Viewer verwenden wir aktuell den größeren Bereich, was sicherlich verwirrend ist. Ich hatte das im git schon geändert. Die werden intern für die "Streaming-Listener" verwendet. Also wenn du den HighContrastImageListener verwendest werden intern die Daten eines ganzen Bildes in mehreren Chunks mit je 64 Bytes abgefragt und am Ende zusammengestellt. Diese Chunks kannst du auch selbst abfragen und zusammenstellen, einen Mehrwert sehe ich da allerdings nicht.

Firmware: Motorized Linear Poti Bricklet 2.0.1 Make sure that the potentiometer value cant oscillate between two values. Download: Motorized Linear Poti

Firmware: Motorized Linear Poti Bricklet 2.0.1 Stelle sicher das Poti-Wert nie zwischen zwei Werten oszillieren kann. Download: Motorized Linear Poti

Danke für das Testen!

Anbei eine neue Version der Firmware, kannst du damit einmal testen? Bei mir kann ich es jetzt nicht mehr reproduzieren in so einen Zustand zu kommen (mit der alten Firmware kann ich es reproduzieren!). Habe mit folgendem Script getestet: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "D1v" from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_motorized_linear_poti import BrickletMotorizedLinearPoti import random def cb_position_reached(position, mlp): print("Position Reached: " + str(position)) mlp.set_motor_position(random.randint(0,100), BrickletMotorizedLinearPoti.DRIVE_MODE_SMOOTH, True) if __name__ == "__main__": ipcon = IPConnection() mlp = BrickletMotorizedLinearPoti(UID, ipcon) ipcon.connect(HOST, PORT) mlp.register_callback(mlp.CALLBACK_POSITION_REACHED, lambda x: cb_position_reached(x, mlp)) mlp.set_motor_position(50, BrickletMotorizedLinearPoti.DRIVE_MODE_SMOOTH, True) raw_input("Press key to exit\n") ipcon.disconnect() motorized-linear-poti-bricklet-firmware.zbin

Puh, ja das ist ganz offensichtlich ein Problem mit der Regelung. Ich baue euren Dauertest mal nach und lasse das mit Debug laufen (Ausgabe von Ist/Sollposition etc). Ich dachte ich hätte das hinreichend getestet, aber anscheinend nicht . Im Code gibt es diese Stelle hier: // We only disable the motor if we are sure that we settled at the new position. // To be sure we wait for 100ms so we can correct an overshoot if(system_timer_is_time_elapsed_ms(motor->hold_position_time, 100)) { motor->position_reached = true; } Meine Vermutung ist, das ihr es schafft eine Stelle anzufahren die genau zwischen zwei Werten ist. Dadurch flackert der Messwert dann innerhalb des 100ms Fensters immer hin und her. Da der Messwert immer nur eine sehr kurze Zeit vom Sollwert abweicht, reicht die Zeit nicht aus um das Poti zu bewegen (Trägheit etc). Das würde auch erklären warum es den Callback nicht gibt. Entweder das If muss raus und die Regelung muss den Punkt gut genug treffen ohne das wir die 100ms Wartezeit benötigen oder ich bringe der Potimessung bei dass sie beim häufigen Wechseln zwischen zwei Werten einfach einen der beiden nimmt .

Pläne haben wir . Kurzfristig wird da allerdings nichts kommen, da fehlen uns aktuell leider die Mitarbeiter. An dieser Stelle nochmal ein Hinweis auf unsere Jobs-Seite: https://www.tinkerforge.com/de/home/jobs/

hübsch

Wir werden da nicht ausstellen, sind aber mindestens einen Tag als Besucher da. Wer Interesse an einem Treffen hat kann sich ja bei uns melden . Einen festen Termin haben wir aber noch nicht.

Das kann ich mir nicht erklären. Entschuldigung für die Probleme! Bitte schicke das Poti ein damit wir uns das angucken können, wir tauschen es natürlich aus. Wenn du sagst dass das Poti während der Kalibrierung die Kanten anfahren kann, dann muss es ja mechanisch prinzipiell funktionieren und der positionsabhängige Widerstand funktioniert nicht richtig.

Offiziell unterstützen wir eine maximale Kabellänge von 2m. Ein 5m Kabel musst du ausprobieren. Das schlimmste was passieren kann sind falsche Werte auf Grund von Bitfehlern.