borg

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.

Hinweis: Dies ist ein großes Update mit einer großen Menge an Code-Änderungen im Backend. Es verbessert drei wichtige Dinge: [*]Fix RS485 Timing-Bug. Dies war ein sehr alter Bug den wir seit Jahren nicht ergründen konnten. Bricklets die I2C nutzen (zum Beispiel Temperature Bricklet) konnten manchmal alle paar 1000 Nachrichten falsche Werte zurückgeben wenn RS485 genutzt wurde. Dies wurde durch eine Mischung von Timing-Anforderungen von I2C/RS485 ausgelöst. Wir nutzen jetzt DMA für I2C um das Problem komplett zu umgehen. [*]Die Handhabung der initialen Enumerierung (Enumerate Callback mit Enumeration Type = CONNECTED) wurde komplett überarbeitet. Doppel-Enumerierungen sind jetzt nicht mehr möglich und die Enumerierung funktioniert auch wenn USB an einen bereits mit Strom versorgten Stapel angesteckt wird. Dadurch wird auch eigentümliches Verhalten an anderen Stellen verbessert. Zum Beispiel: Wenn in einem RS485-Netz der RS485-Master neugestartet wurde, mussten auch die RS485-Slave neugestartet werden damit diese sich Re-Enumerieren. Mit der neuen Firmware Re-Enumerieren sich die Slaves automatisch sobald sich der Master Re-Enumeriert. [*]Es gibt jetzt kein durch USB ausgelöstes hartes Reset mehr. USB hat reset/suspend/resume Nachrichten, welche in den alten Firmwares ein Hardware Reset auslösen konnten. Mit der neuen Firmware wird die USB State-Machine zurückgesetzt (wie vom PC angefordert), aber alles andere wird im Betrieb gehalten. Die Bricks/Bricklets verlieren also keinerlei Statusinformationen. Ein Stepper Brick wird zum Beispiel den Schrittmotor weiter ansteuern bis die Nachricht abgearbeitet ist. Von der Perspektive des PCs wird der Brick getrennt und sofort wieder verbunden und eine neue Enumerierung wird gesendet. Falls du aktuell Probleme mit unerwünschten Resets hast (zum Beispiel beim Schalten von induktiven Lasten mit Relais) wird diese Änderung das Problem wahrscheinlich lösen! Der PC wird zwar weiterhin USB zurücksetzen, allerdings bleibt alles am laufen und es gehen keine Nachrichten verloren o.ä. Firmwares: DC Brick 2.3.5, IMU Brick 2.3.5, IMU 2.0 Brick 2.0.10, Master Brick 2.4.6, Servo Brick 2.3.5, Silent Stepper Brick 2.0.4, Stepper Brick 2.3.6 Stelle sicher das Bricks nicht mehr durch suspend/resume neugestartet werden [alle] Refactor initialie Enumerierung über USB/SPI [alle] und RS485/Chibi [nur Master Brick] Fix Doppelenumerierungs-Bug [alle] Verbessere co-mcu Bricklet Reset-Behandlung [alle] Verbessere I2C-Kommunikation (Nutze DMA im synchronen Fall) [alle] Verbessere RS485 State-Machine (Nutze Hardware Timer statt Busy Waiting) [nur Master Brick] Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick Plugins: Temperature Bricklet 2.0.4 Nutze bricklib für I2C-Kommunikation (aktiviert DMA für I2C, siehe oben) Download: Temperature Bricklet

Please note: This is a big update with many big changes in the backend code. It improves three important things: [*]Fix RS485 Timing bug. This is a very old bug that we were not able to figure out for many years. Bricklets that use I2C (for example Temperature Bricklet) would somtimes give false values every few 1000 messages if RS485 was used. This was caused by a mix of I2C/RS485 timing constraints. We now use DMA for I2C Messages to fix this. [*]The handling of the initial enumeration (the enumerate callback with enumeration type = CONNECTED) has been completely reworked. Double enumerations don't happen anymore and the enumeration also works if a USB cable is connected to an already powered stack. This also fixes some other strange behavior. For example: In a RS485 network, if you restarted the RS485 master stack you had to restart the slave stacks as well, otherwise they wouldn't enumerate again. With the update the RS485 slaves will automatically re-enumerate if the RS485 master re-enumerates itself. [*]We will now never do a real hard reset if triggered by USB. USB has reset/suspend/resume messages that triggered a hardware reset. With the new firmwares the USB state machine will be properly reset (as requested by the PC), but everything else will keep on running. So the Bricks/Bricklets will not loose state and for example a stepper motor will keep running until the request is fully processed. From the PC perspective the Brick will disconnect and immediately connect again. A new initial enumeration will be send. If you have problems with unwanted resets (for example if a relay switches an inductive load) this will probably fix this issue! The PC will still reset the USB, but from the user perspective everything will keep running and working, no lost messages or similar. Firmwares: DC Brick 2.3.5, IMU Brick 2.3.5, IMU 2.0 Brick 2.0.10, Master Brick 2.4.6, Servo Brick 2.3.5, Silent Stepper Brick 2.0.4, Stepper Brick 2.3.6 Make sure Brick does not restart on suspend/resume anymore [all] Refactor initial enumeration handling for USB/SPI [all] and RS485/Chibi [only Master Brick] Fix double-enumeration bug [all] Improve co-mcu Bricklet reset handling [all] Improve I2C communication (Use DMA in synchronous case) [all] Improve RS485 state machine (Use hardware timer instead of busy waiting) [only Master Brick] Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick Plugins: Temperature Bricklet 2.0.4 Use bricklib for I2C communication (enables DMA for I2C, see above) Download: Temperature Bricklet

Oh, das ist ja seltsam . Das Bricklet sollte auf jeden Fall kalibriert ausgeliefert werden. Kann du testweise in deinem Programm einmal die "calibrate()"-Funktion aufrufen? Da sollte das Bricklet dann einmal mit voller Wucht die beiden Kanten anfahren und sich Kalibrieren. Nach dem kalibrieren sollte es dann auch 0,5mm vor der Kannte halt machen nicht mehr mit einem lauten "Klack" auffahren. Das wäre auf Dauer auch nicht gut für den Zahnriemen. Die Kalibrierung wird im Flash gespeichert, muss also nur einmal gemacht werden.

Der Bootloader-Modus ist Teil der Hardware des Microcontrollers, wir haben da keinerlei Kontrolle mehr drüber sobald der Microcontroller in dem Modus ist. Da läuft dann keine Software von uns mehr. Das Verhalten hat hier also technische Gründe.

Mit der 80x60 Auflösung nutzen wir >90% der verfügbaren Bandbreite (sprich mit dem Lepton3 hätte man nur ~2fps) und die 160x120 Pixel des Lepton3 würden auch nicht in den RAM den Prozessors passen. Sieht also leider schlecht aus, das geht zumindest nicht so einfach mit dem Bricklet. Das RED Brick Image 1.9 ist prinzipiell kompatibel, wurde aber vor den neue Bricklets veröffentlicht und hat entsprechend die Bindings noch nicht. Du kannst aber das 1.9er Image nehmen und die Bindings aktualisieren.

Ich weiß nicht wieviel IR da noch ankommt von anderen Planeten. Du wirst sicherlich die Temperatur von Wolken (und allgemein von der Luftfeuchte nehme ich an) und atmosphärische "Rückabstrahlungen" und so weiter messen. Ob da noch genug IR-Strahlung vom Planeten überbleibt? Gibt es überhaupt Wärmebilder von Planeten die von der Erde aufgenommen wurden?

Der Shutter ist aus einem Material mit bekannter Emissivität und Temperatur (es sitzen Temperatursensoren auf dem Shutter). Der wird alle paar Sekunden kurzzeitig vor den Wärmebildsensor gehalten um den Sensor neu zu kalibrieren. Das hat in diesem Fall also nichts mit der Belichtungszeit zu tun, wie man es von einer DSLR kennt.

Welche Version hat das RED Brick Image? Hast das schon Support für die neuen Co-Prozessor Bricklets (>= 1.9)? Siehe hier: https://www.tinkerunity.org/forum/index.php?topic=4128.0

The source code of the logger of the Brick Viewer has something like this in it: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/data_logger/loggable_devices.py

Neue Bricklets Teil 3 - RGB LED Matrix Bricklet und Thermal Imaging Bricklet Blogeintrag

Neue Bricklets Teil 2 - Motorized Linear Poti Bricklet und RGB LED Button Bricklet Blogeintrag

New Bricklets Part 3 - RGB LED Matrix Bricklet and Thermal Imaging Bricklet Blog Entry

New Bricklets Part 2 - Motorized Linear Poti Bricklet and RGB LED Button Bricklet Blog Entry

So, für C# gibt es jetzt 3 Beispiele: https://www.tinkerforge.com/de/doc/Software/Bricklets/ThermalImaging_Bricklet_CSharp.html Eins erzeugt einfach nur den Callback und von da aus kann man die Daten nutzen, eins holt ein einzelnes Wärmebild und speichert es als PNG und das letzte zeigt ein Wärmebild Live Video in einem Windows.Form. Für die meisten Projekte sollte das einen guten Einstieg bieten . Die Pseudofarben-Palette wird bei den letzten beiden Beispielen auch erstellt und benutzt, die Funktion dafür kann man leicht einzeln rauskopieren wenn man sie benötigt. Da erstelle ich aber auch noch eine programmiersprachenunabhängige Sektion in der Dokumentation zu.

Die Beispiele für die neuen Bricklets sind noch nicht komplett fertig, kommen aber noch! Da gibt es dann natürlich auch eins für C#. GetThermal erwartet wenn ich das richtig sehe eine USB Video Class, das kann das Bricklet leider nicht, es wird unser ganz normales Protokoll genutzt.

Neue Bricklets - LEDs, Motorized Poti, Wärmebildkamera Blogeintrag

New Bricklets - LEDs, Motorized Poti, Thermal Imaging Camera Blog Entry

Wir wollten ursprünglich die Schraubklemme bestücken, waren aber noch nicht sicher ob nach oben oder nach unten. Beschriftung hatten wir vorsichtshalber auf beide Seiten gemacht. Nachdem wir das dann hier selbst ein wenig getestet hatten hat uns beides nicht gefallen. Die Schraubklemme nach oben ragt so weit heraus (was ist wenn man das in eine Gehäusewand o.ä. befestigen möchte?). Wenn man die Schraubklemme nach unten macht liegt das Bricklet nicht mehr flach auf und es kippelt immer wenn man es auf den Tisch legt. So richtig flache Schraubklemmen o.ä. die in das 5.0mm Raster gepasst hätten haben wir nicht gefunden. Da haben wir uns dann dazu entschieden einfach ein 15cm Stück Kabel anzulöten, von da aus kann man dann mit einer WAGO-Klemme weiter verbinden. Die Leiterplatte kippelt nicht und es ragt auch noch oben hin nichts 1cm über.