Uhlhorn Posted February 27, 2019 at 01:30 AM Posted February 27, 2019 at 01:30 AM Moin, seit ein paar Tagen habe ich einen Silent Stepper 2.0 und der macht Probleme. Wenn ich das USB-Kabel in den Master stecke, erscheint der Stepper Brick, aber jede Änderung im Brick Viewer werden nicht mehr ausgeführt, auch nicht die Änderung der Status-LED. Nach ein paar Sekunden verschwinden alle Bricks aus dem Brick Viewer. Anfangs funktionierte der Stepper Brick. Die Probleme begannen mit der Programmierung des Bricks. @ Tinkerforge: In der Doku steht nirgends, was die Tasten „Reset“ und „Erase“ genau machen. Das sollte man vielleicht noch hinzufügen. ;-) Quote
Uhlhorn Posted February 27, 2019 at 01:48 AM Author Posted February 27, 2019 at 01:48 AM Nach studieren der FAQ wollte ich den Silent Stepper 2.0 neu flashen, doch jetzt ist er ganz tot. :-( Ich habe die Tasten versehentlich falsch gedrückt: Reset gedrückt und gehalten Erase gedrückt und gehalten Reset losgelassen Erase losgelassen. Jetzt geht keine LED mehr und ich bekomme immer die Meldung „Could not connect to Brick“. Und nun?!? Quote
Uhlhorn Posted February 27, 2019 at 01:53 AM Author Posted February 27, 2019 at 01:53 AM Oh, jetzt kann ich ohne wieder flashen. :-) Ich habe ein paar Mal den Port hin und her geschaltet (was ich vorher aber schon gemacht habe). Aber davor habe ich erst versucht mit „Connect“ eine Verbindung hinzubekommen. Irgendwie scheint mir der Brick Viewer sehr buggy zu sein, kann das sein? Quote
Uhlhorn Posted February 27, 2019 at 02:27 AM Author Posted February 27, 2019 at 02:27 AM Also, manchmal geht es eine ganze Weile, manchmal nicht. Dann bekomme ich eine Fehlermeldung in meinem Programm, wobei ein Teil wohl aus anderen Modulen kommt: bricklet_rotary_encoder_v2.pyip_connection.py File "/Users/gerhard/PycharmProjects/RedBrick/tinkerforge/bricklet_rotary_encoder_v2.py", line 124, in get_count return self.ipcon.send_request(self, BrickletRotaryEncoderV2.FUNCTION_GET_COUNT, (reset,), '!', 'i') File "/Users/gerhard/PycharmProjects/RedBrick/tinkerforge/ip_connection.py", line 1173, in send_request raise Error(Error.TIMEOUT, msg) tinkerforge.ip_connection.Error: Did not receive response for function 1 in time (-1) Vielleicht hilft das ja bei der Analyse. Quote
jgmischke Posted February 27, 2019 at 08:09 AM Posted February 27, 2019 at 08:09 AM Hallo, der Brickviewer ist normalerweise sehr stabil, habe da seit Jahren nie Probleme mit. Kann es sein, das dein USB Kabel defekt ist? Die Fehlermeldung sagt ja aus, das da keine Verbindung gefunden wird. Quote
Uhlhorn Posted February 27, 2019 at 03:00 PM Author Posted February 27, 2019 at 03:00 PM Wenn ich Bewegungsanweisungen per set_steps() an den Treiber sende und diese immer wieder mit full_brake() unterbreche um anschließend eine neue Bewegung zu starten, dann hängt er sich immer mal wieder wie beschrieben auf. Das kann man manuell in Brick Viewer provozieren oder mit einem Script über USB-Kabel und auch mit einem Script auf dem Red Brick, also ohne USB-Kabel. Der läuft also nicht stabil! Zumindest meiner nicht. Ich werde heute Nacht mal ein hier gekauftes nagelneues USB-Kabel verwenden. Nur um sicher zu sein. Dann werde ich außerdem ein Script erstellen, welches zufällige Bewegungen in schneller Folge erzeugt. Ich bin mir sicher, dass ich damit den Brick zum Aufhängen bekomme. ;-) Quote
photron Posted February 27, 2019 at 03:19 PM Posted February 27, 2019 at 03:19 PM Diese "Could not connect to Brick" Meldung beim Flashen ist komisch. Da tritt intern in brickv ein unerwarteter Fehler auf. Wir haben das jetzt verbessert und brickv meldet unerwarteter Fehler jetzt mit mehr Details. Teste mal bitte diese Version: http://download.tinkerforge.com/tools/brickv_pyqt5/beta2/macos/brickv_macos_2_4_0_uhlhorn.dmg Flash damit bitte den Brick nochmal. Ich würde gerne sehen welchen Fehler du da erzeugen kannst denn ich hier nicht reproduziert bekomme. Bezüglich instabiler Silent Stepper Brick: Da gibt es aktuell keine bekannten Problem. Die Theorie mit dem defekten/wackeligen USB Kabel ist aber eine gute. Wenn du in allen Testes das selbe USB Kabel verwendest dann spielt es natürlich keine Rolle, ob du das einen Master oder RED Brick zwischen hast. Quote
Uhlhorn Posted February 27, 2019 at 03:26 PM Author Posted February 27, 2019 at 03:26 PM Wenn du in allen Testes das selbe USB Kabel verwendest dann spielt es natürlich keine Rolle, ob du das einen Master oder RED Brick zwischen hast. Das Problem tritt auch ganz ohne USB-Kabel auf, wenn ich das Programm auf dem Red Brick ausführe. Und es ist (bei mir) reproduzierbar. Wir haben das jetzt verbessert und brickv meldet unerwarteter Fehler jetzt mit mehr Details. Teste mal bitte diese Version: … Flash damit bitte den Brick nochmal. Ich würde gerne sehen welchen Fehler du da erzeugen kannst denn ich hier nicht reproduziert bekomme. Das werde ich gerne machen. Quote
Uhlhorn Posted February 27, 2019 at 08:37 PM Author Posted February 27, 2019 at 08:37 PM So, ich habe jetzt ein Programm, das den Motor mit zufälligen Werten dreht. Und das hängt sich manchmal nach ein paar Minuten auf, manchmal läuft es auch ’ne viertel Stunde oder so. Hier habe ich mal ein nicht gelistetes Video dazu gemacht. Der Stack besteht (von unten nach oben) aus einer Stromversorgung, einem Red Brick, einem Master, einem DC und dem Silent Stepper. Das Rotary Bricklet ist an den Stepper angeschlossen. Die Stromversorgung hängt an dem untersten Modul. Die Versionen der Module sind im Screenshot zu sehen. Hier das Video: Danach habe ich dasselbe nur mit der Stromversorgung, dem Master und dem Stepper gemacht. Auch das hängt sich auf. Hier das Programm dazu, was allerdings noch etwas unaufgeräumt ist. Ich habe halt damit experimentiert. #!/usr/bin/env python # -*- coding: utf-8 -*- # python 3 HOST = "localhost" PORT = 4223 UID_r = "Ehv" # Change XYZ to the UID of your Rotary Encoder Bricklet 2.0 UID_s = "5VH7xb" # Change XXYYZZ to the UID of your Silent Stepper Brick from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_silent_stepper import BrickSilentStepper from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_rotary_encoder_v2 import BrickletRotaryEncoderV2 from random import * import time alt = 0 Zeitpunkt = time.time() + 10.1 ZeitDiff = time.time() - Zeitpunkt if __name__ == "__main__": ipcon = IPConnection() # Create IP connection re = BrickletRotaryEncoderV2(UID_r, ipcon) # Create device object ss = BrickSilentStepper(UID_s, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected ss.set_motor_current(800) # 800mA ss.set_step_configuration(ss.STEP_RESOLUTION_64, True) # 1/8 steps (interpolated) ss.set_max_velocity(4000) # Velocity 2000 steps/s # Slow acceleration (500 steps/s^2), # Fast deacceleration (5000 steps/s^2) ss.set_speed_ramping(1000, 1000) ss.set_basic_configuration(1, 800, 0, 1000, 500, 500, 1000, 1) while 1: # Get current count without reset count = re.get_count(False) Schritte = round(random()*100000)+10000 Richtung = round(random()) Zeit = round(random()*30+1,1) Geschwindigkeit = round(random()*40000)+15000 Beschleunigung = round(random()*40000)+10000 if ZeitDiff <= 0: if Richtung == 1: # Rechts drehen ss.full_brake() ss.enable() # Enable motor power print("Schritte: " + str(Schritte)) if Richtung == 1: print("Richtung: rechts") else: print("Richtung: links") print("Zeit: " + str(Zeit)) print("Geschwindigkeit: " + str(Geschwindigkeit)) print("Beschleunigung: " + str(Beschleunigung) + "\n") ss.set_speed_ramping(Beschleunigung, Beschleunigung) ss.set_max_velocity(Geschwindigkeit) ss.set_steps(Schritte) # Drive „Schritte“ steps forward Zeitpunkt = time.time()+Zeit if Richtung == 0: # Links drehen ss.full_brake() ss.enable() # Enable motor power print("Schritte: " + str(Schritte)) if Richtung == 1: print("Richtung: rechts") else: print("Richtung: links") print("Zeit: " + str(Zeit)) print("Geschwindigkeit: " + str(Geschwindigkeit)) print("Beschleunigung: " + str(Beschleunigung) + "\n") ss.set_speed_ramping(Beschleunigung, Beschleunigung) ss.set_max_velocity(Geschwindigkeit) ss.set_steps(-Schritte) # Drive „Schritte“ steps backward Zeitpunkt = time.time()+Zeit ZeitDiff = Zeitpunkt-time.time() #print("ZeitDiff: "+str(ZeitDiff)) #print(" ") if ss.get_current_velocity() == 0: ss.disable() ZeitDiff = -1 input("Press key to exit\n") # Use input() in Python 3 ss.disable() ipcon.disconnect() Quote
borg Posted February 28, 2019 at 09:49 AM Posted February 28, 2019 at 09:49 AM Läuft das Programm auf dem RED Brick denn noch weiter oder gibt es da eine Exception o.ä.? Eine andere Frage: Ist das RED Brick in dem Aufbau notwendig um den Fehler zu erzeugen? Wenn du einmal testweise den Silent Stepper Brick direkt am PC/Laptop anschließt und das Python Programm dort startest, tritt das Problem dann auch auf? Du könntest auch einmal testweise den RED Brick am PC anschließen und das Python Programm vom PC starten. Quote
Uhlhorn Posted February 28, 2019 at 11:54 AM Author Posted February 28, 2019 at 11:54 AM Der Fehler tritt in jeder Kombination auf. Und wenn das Programm auf dem PC läuft, bekomme ich die obige Fehlermeldung. Die Fehlermeldung vom Red Brick muss ich nachliefern. Quote
borg Posted February 28, 2019 at 12:05 PM Posted February 28, 2019 at 12:05 PM OK, ich werde versuchen das hier zu reproduzieren. D.h. der Minimalaufbau mit dem ich das nachstellen kann wäre ein Silent Stepper Brick mit Schrittmotor und externer Stromversorgung per USB am PC und dazu dein Python-Programm ausführen, richtig? Quote
Uhlhorn Posted February 28, 2019 at 12:26 PM Author Posted February 28, 2019 at 12:26 PM Ja, das sollte gehen. Bei meinen Versuchen lief es so etwas länger, was aber auch Zufall sein kann. Ich bin mir noch nicht sicher, ob der Rotary Encoder einen Einfluss hat. Ich habe noch nicht alle Kombis durch. Quote
borg Posted February 28, 2019 at 03:11 PM Posted February 28, 2019 at 03:11 PM Hab das jetzt (inklusive Rotary Encoder) hier aufgebaut und gestartet. Bisher läuft es durch. Das erste was mir bei dem Script auffällt: Du rufst get_count() des Rotary Encoders und get_current_velocity() des Stepper Bricks mehr oder weniger in einer "While-True-Schleife" auf. Du könntest an der Stelle entweder ein sleep von 50ms oder so einbauen um das ganze ein bisschen zu entlasten oder sogar den Count per Callback holen und in der Schleife nur drauf reagieren wenn der Count sich ändert. So wie es gebaut ist lastet das den Stepper Brick und Rotary Encoder voll aus. Deswegen sollte das natürlich nicht abstürzen, nur als Hinweis. Quote
Uhlhorn Posted February 28, 2019 at 03:54 PM Author Posted February 28, 2019 at 03:54 PM Habe gerade mein Netzteil bekommen. Nun teste ich es mal in der Minimalkonfiguration. Dafür muss die Zeile 44 für den Rotary Encoder auskommentiert werden, damit das Script läuft. Ich teste es gerade und im Moment läuft er gerade störungsfrei. :-/ Ich lasse ihn mal länger laufen. Quote
Uhlhorn Posted February 28, 2019 at 04:37 PM Author Posted February 28, 2019 at 04:37 PM Hmm, jetzt läuft es störungsfrei. Vielleicht bricht die Akkuspannung zu sehr ein, dass sie diese Probleme verursacht. Ich teste das nachher noch mal mit dem Akku. Quote
borg Posted February 28, 2019 at 04:48 PM Posted February 28, 2019 at 04:48 PM Die API hat auch einen Callback dafür: https://www.tinkerforge.com/de/doc/Software/Bricks/SilentStepper_Brick_Python.html#BrickSilentStepper.CALLBACK_UNDER_VOLTAGE Quote
Uhlhorn Posted February 28, 2019 at 05:32 PM Author Posted February 28, 2019 at 05:32 PM Es lief jetzt eine ganze Zeit lang gut. Jetzt habe ich wieder den Stepper auf den den Red Brick gesetzt. Und schon habe ich sofort Ausfälle. Ich habe jetzt einen PTC (will Motortemperatur messen) und den Rotary Encoder an den Silent Stepper angeschlossen und bekomme nur noch Timeouts! Quote
Uhlhorn Posted February 28, 2019 at 05:46 PM Author Posted February 28, 2019 at 05:46 PM Also, ich habe jetzt einen Master, den Silent Stepper, ein Netzteil und ein Schrittmotor. Der Master ist unter den Stepper gesteckt. Schließe ich das USB-Kabel an den Master an, hängt sich der Stepper nach kurzer auf. Schließe ich es an den Stepper an, läuft es länger. (Zumindest hängt es sich nicht so schnell auf. Ich mache mal einen Langzeittest) Quote
Uhlhorn Posted February 28, 2019 at 07:02 PM Author Posted February 28, 2019 at 07:02 PM So, hier ist eine Minimalkonfiguration: Ich verwende nur einen Master und einen Stepper, keine weiteren Bricks oder Bricklets. (Und ich verwende das Netzteil und nicht den Akku, Letzteren habe ich nur für’s Foto als Symbolstromquelle genommen.) Stecke ich das USB-Kabel in den Master und lasse mein Programm auf dem PC laufen hängt sich das Ganze sehr schnell auf.Stecke ich das USB-Kabel in den Stepper, läuft alles problemlos (getestet über 40 Minuten) Ich habe es auch mit Bricklets (Rotary Encoder + PTC) am Stepper angeschlossen probiert. Auch das verursacht nicht das Problem. Das Problem scheint irgendwie bei der Kommunikation zwischen den Bricks zu liegen. Es tritt zwischen Stepper und Red Brick auf wie auch zwischen Stepper und Master. In den Fotos sind beine Minimalaufbauten zu sehen. Am Ende hängt das modifizierte Programm (Motorströme verringert, Thresholds hoch gesetzt, Rotary Encoder auskommentiert) #!/usr/bin/env python # -*- coding: utf-8 -*- # python 3 HOST = "localhost" PORT = 4223 UID_r = "Ehv" # Change XYZ to the UID of your Rotary Encoder Bricklet 2.0 UID_s = "5VH7xb" # Change XXYYZZ to the UID of your Silent Stepper Brick from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_silent_stepper import BrickSilentStepper from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_rotary_encoder_v2 import BrickletRotaryEncoderV2 from random import * import time alt = 0 Zeitpunkt = time.time() + 10.1 ZeitDiff = time.time() - Zeitpunkt if __name__ == "__main__": ipcon = IPConnection() # Create IP connection re = BrickletRotaryEncoderV2(UID_r, ipcon) # Create device object ss = BrickSilentStepper(UID_s, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected ss.set_motor_current(500) # 800mA ss.set_step_configuration(ss.STEP_RESOLUTION_64, True) # 1/8 steps (interpolated) ss.set_max_velocity(4000) # Velocity 2000 steps/s # Slow acceleration (500 steps/s^2), # Fast deacceleration (5000 steps/s^2) ss.set_speed_ramping(1000, 1000) ss.set_basic_configuration(1, 250, 10, 1000, 65535, 65534, 65535, 1) #ss.set_basic_configuration(1, 250, 10, 1000, 65535, 65536, 65536, 1) while 1: # Get current count without reset #count = re.get_count(False) Schritte = round(random()*100000)+10000 Richtung = round(random()) Zeit = round(random()*30+1,1) Geschwindigkeit = round(random()*40000)+15000 Beschleunigung = round(random()*40000)+10000 if ZeitDiff <= 0: if Richtung == 1: # Rechts drehen ss.full_brake() ss.enable() # Enable motor power print("Schritte: " + str(Schritte)) if Richtung == 1: print("Richtung: rechts") else: print("Richtung: links") print("Zeit: " + str(Zeit)) print("Geschwindigkeit: " + str(Geschwindigkeit)) print("Beschleunigung: " + str(Beschleunigung) + "\n") ss.set_speed_ramping(Beschleunigung, Beschleunigung) ss.set_max_velocity(Geschwindigkeit) ss.set_steps(Schritte) # Drive „Schritte“ steps forward Zeitpunkt = time.time()+Zeit if Richtung == 0: # Links drehen ss.full_brake() ss.enable() # Enable motor power print("Schritte: " + str(Schritte)) if Richtung == 1: print("Richtung: rechts") else: print("Richtung: links") print("Zeit: " + str(Zeit)) print("Geschwindigkeit: " + str(Geschwindigkeit)) print("Beschleunigung: " + str(Beschleunigung) + "\n") ss.set_speed_ramping(Beschleunigung, Beschleunigung) ss.set_max_velocity(Geschwindigkeit) ss.set_steps(-Schritte) # Drive „Schritte“ steps backward Zeitpunkt = time.time()+Zeit ZeitDiff = Zeitpunkt-time.time() #print("ZeitDiff: "+str(ZeitDiff)) #print(" ") if ss.get_current_velocity() == 0: ss.disable() ZeitDiff = -1 input("Press key to exit\n") # Use input() in Python 3 ss.disable() ipcon.disconnect() Quote
borg Posted March 1, 2019 at 08:52 AM Posted March 1, 2019 at 08:52 AM Ich hab das jetzt eine ganze Weile am laufen hier (im Stapel mit Master Brick), bisher kann ich es leider noch nicht reproduzieren . Der Aufbau mit nur Rotary Encoder und Silent Stepper Brick lief die ganze Nacht duch. Quote
Uhlhorn Posted March 1, 2019 at 07:23 PM Author Posted March 1, 2019 at 07:23 PM Merkwürdig. Bei mir verabschiedet sich das Programm immer mit dem obigen Fehler, wenn ich den Stepper nicht direkt ansteuere. Und das immer innerhalb von wenigen Minuten. Vielleicht ist ja etwas mit dem Stepper nicht in Ordnung. Nur wenn ich das USB-Kabel direkt anschließe, läuft es zuverlässig. Quote
borg Posted March 1, 2019 at 09:03 PM Posted March 1, 2019 at 09:03 PM Der Aufbau lief bei mir über 9 Stunden durch. Übers Wochenende hab ich es jetzt aber nicht laufen lassen, aber ich kann es dann am Montag wieder starten. Vielleicht ist ja etwas mit dem Stepper nicht in Ordnung. Mh, eher ist was mit dem Master Brick nicht in Ordnung oder? Der Stepper Brick alleine funktioniert ja. Kannst du einmal überprüfen ob vielleicht ein Pin im Bricklet-Stecker krumm ist und einen Kurzschluss macht o.ä. (in einem der Bricks oder Bricklets)? Ist irgendetwas im Stapel-Stecker was dazu führt das der Kontakt nicht gut ist? Aber das alles würde nicht erklären warum du Zeile 0-2 im OLED nicht setzen kannst... Vielleicht einen anderen USB-Port am PC oder ein anderes USB-Kabel? Dein Aufbau ist ja eigentlich recht simpel, dass muss absolut stabil laufen. Quote
Uhlhorn Posted March 1, 2019 at 11:42 PM Author Posted March 1, 2019 at 11:42 PM Das sind ja alles ganz neue Module. Die Stecker sind alle in Ordnung, die sind auch nicht zu fein für mich, ich kann schon seit den 90er Jahren SMD löten. ;-) Jedenfalls keine umgeknickten Beine, kein Schmutz, nichts Auffälliges. Jetzt teste ich das Programm mal vom Red Brick aus. Wenn dort der Fehler auch auftritt, liegt es nicht am USB-Port oder Kabel. :-) Quote
borg Posted March 2, 2019 at 12:26 AM Posted March 2, 2019 at 12:26 AM Der Aufbau mit RED Brick ist im Vergleich zum anderen Aufbau leider schwerer zu debuggen. Das hat auch mehr Komplexität (SD Karte, CPU Last bei dem "While-True"-Programm auf dem RED Brick etc). Eine andere Frage: Du bekommst jedes mal eine TimeoutException, richtig? Per Default haben wir einen 2,5 Sekunden Timeout im System. D.h. wenn es auf eine Anfrage an den Brick für 2,5 Sekunden keine Antwort gibt, fliegt die Exception. Du könntest diesen Timeout einmal testweise erhöhen (set_timeout auf der IPConnection aufrufen): https://www.tinkerforge.com/en/doc/Software/IPConnection_Python.html Am besten auf 30 Sekunden oder so stellen, damit wir ganz sicher sein können das auch wirklich eine Nachricht verloren geht und nicht nur für eine längere Zeit irgendwo stecken bleibt. Weitere Frage: Wenn die TimeoutException auftritt, kannst du danach dein Programm wieder starten und es läuft erst normal weiter? Quote
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.