Quantasy Posted December 19, 2017 at 07:09 PM Share Posted December 19, 2017 at 07:09 PM Wir haben die neuen Potis einem brutalen Dauertest unterzogen: 1. Befehle dem Motor, das Poti an einen beliebigen Ort zu fahren 2. Warte bis die Position erreicht wurde (Callback positionReached) 3. Warte eine gewisse Zeit (bis zu einer Sekunde) 4. Goto 1 Bei sämtlichen Potis ist dann folgendes zu beobachten: Manchmal (etwa 1/800 mal) kann der Motor die Position nicht 'exakt' erreichen... und der Motor summt vor sich hin... Der Wert des Potis (per getPosition im Brickviewer) flackert dabei auf dem gewünschten Wert und einem daneben. Der Callback (positionReached) wird in diesem Fall aber nie ausgelöst. (Dabei ist es egal ob sanft oder hart gefahren wird, und ob die Position gehalten wird oder nicht. Der Hänger tritt in jedem Fall auf.) Eine subtile Erschütterung erst lässt die Endposition dann aber doch zu und der Motor verstummt... es geht weiter... bis zum nächsten 'Hänger'... So ein 'Hänger' kann über Stunden aufrecht erhalten werden und lässt sich nur 'manuell' lösen. (Der Motor summt dabei stets, wird aber nicht weiter warm) Wäre es denkbar, dass ihr da intern ein wenig am PID korrigiert, oder dass ihr den Callback ein bisschen 'lascher' auslöst? Sonst können wir die Poti's nicht im Show-Room neben der Warp-Spule laufen lassen (oder nur auf einer Rüttelplatte :-) )... Und das wäre ja wirklich schade ;-) Quote Link to comment Share on other sites More sharing options...
borg Posted December 19, 2017 at 09:05 PM Share Posted December 19, 2017 at 09:05 PM 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 . Quote Link to comment Share on other sites More sharing options...
borg Posted December 20, 2017 at 02:34 PM Share Posted December 20, 2017 at 02:34 PM 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 Quote Link to comment Share on other sites More sharing options...
Quantasy Posted December 22, 2017 at 12:59 PM Author Share Posted December 22, 2017 at 12:59 PM Nach Einspielen der Firmware kann auch ich vermelden, dass sämtliche unsere Potis den beschriebenen Fehlerzustand auch nach über 8h Dauertest nie mehr erreicht haben. Wir haben dabei sämtliche Modi (Hard/Smooth) und (Hold: true/false) berücksichtigt. Super! Ich erkenne das Problem als gelöst. Quote Link to comment Share on other sites More sharing options...
borg Posted December 22, 2017 at 01:17 PM Share Posted December 22, 2017 at 01:17 PM Danke für das Testen! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.