photron

Brick Viewer 1.1.2 LCD 16x2 Plugin verwendet jetzt richtige write_line Signatur Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.1 Verbesserte Flashing Fehlermeldungen Datei-Öffnen Dialoge merken sich das zuletzt verwendete Verzeichnis "Show this message again" Checkbox in Fehlermeldungen funktionieren Host und Port Einstellung werden gespeichert Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.8 Break a reference cycle between USBDevice and USBTransfer objects Add date to log output Fix stack ID routing for enumerate with multiple connected stacks Add --version commandline argument Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.8 Reference Cycle zwischen USBDevice und USBTransfer Objekten gebrochen Datum in Logeinträgen Stack ID Routing für Enumerate mit mehreren verbundenen Stacks korrigiert Kommandozeilenparameter --version hinzugefügt Downloads: Windows, Linux, Mac OS X

There was no central place for announcements about new versions of Brick Daemon and Viewer, the different programming language bindings as well as firmwares and plugins. This thread is going to improve this. New software and hardware will be announced here

Bisher gab es keine zentrale Stelle an der auf neue Versionen von Brick Daemon und Viewer, der verschiedenen Programmiersprachen Bindings sowie Firmwares und Plugins hingewiesen wurde. Dieser Thread soll dem nun Abhilfe schaffen. Hier wird zukünftig auf die Veröffentlichung neuer Software und Hardware aufmerksam gemacht

Seit einer Weile steht die Brickv Version in der Titelleiste des Hauptfensters. Brickd hat heute mit Version 1.0.8 ein --version Kommandozeilenparameter bekommen. Darüber hinaus haben jetzt auch Brickd und Brickv im Programmefenster der Systemsteuerung unter Windows ihre Versionsnummer im Namen des Eintrags.

Vom Log her sieht das Problem exakt so aus wie beim letzten Mal. Der Read Callback ist fehlgeschlagen und dann ging nix mehr. Das ein Neustart von brickd reicht um das Problem zu beheben deutet darauf hin, dass brickd da möglicherweise zu pessimistisch ist. Mich interessiert sehr ob meine vorgeschlagene Änderung in usb_device.py ('self.alive = False' in Zeile 304 auskommentieren) nicht schon reicht um einen Teil es Problems zu beheben. Nämlich den Teil bei dem in brickd Neustart alleine hilft. Das ist möglich, es gibt hier im Forum in paar Leute die definitiv mit EMV Probleme haben. Wir denken da im Moment über Lösungen nach wie man das längerfristig hardware- und softwaremäßig robuster machen kann im Hinblick auf EMV. Das ist allerdings nichts was eben auf die Schnelle geht. Du könntest mal Xennas Lösung testen. Da hat es geholfen die Bricks und Bricklets in eine Keksdose aus Metal zu stecken und so zu schirmen: http://www.tinkerunity.org/forum/index.php/topic,601.msg4008.html#msg4008 Das mag für deine Temperaturmessung nicht die idealste Lösung sein Ansonsten kann ich nur nochmal raten die 100kHz Firmware für das Temperature Bricklet bei Gelegenheit zu testen.

Nifty, danke für den Hinweis. Das Problem ist in Version 1.1.2 behoben.

pluto, das ist ja mal ganz schön von hinten durch die Brust in's Auge Ich sehe aber gerade gar nicht warum du das so tust. Ich bin gerade mit den Delphi Bindings beschäftigt und das läuft wunderbar unter Lazarus Die Timeline setzt Delphi Bindings für nächste Woche an. Ich denke das kann ich einhalten.

Brick Viewer 1.1.1 merkt sich jetzt was du für Host und Port eingestellt hast.

Brick Viewer version 1.1.1 now remembers host and port information.

Wenn du den Treiber aus dem Brick Daemon drivers Verzeichnis richtig für den Master installierst hast, dann ist jetzt im Geräte Manager kein "Master Brick" mehr ausgeführt sondern ein "Brick_Driver" in der Kategorie "libusb (WinUSB) devices". Ist das bei dir jetzt so?

Du füllst erst dann mit Leerzeichen auf, wenn n < 0, wenn also der Text links anfängt rauszuscrollen. Das geht wenn der Text 20 Zeichen oder länger ist. Dein Text für die erste Zeile ist kürzer als 20 Zeichen, alle anderen sind länger. Daher tritt das Problem nur bei der ersten Zeile auf.

Gut du hast den Master wieder geflashed bekommen. Wenn im Geräte Manager ein Master Brick mit gelben Fragezeichen steht, dann hat Windows den Brick als USB Gerät gefunden, es fehlt aber noch der Treiber. Diesen Treiber findest du im drivers Verzeichnis des Brick Daemons und kannst ihn genau so installieren wie zuvor den anderen Treiber. Wenn der Treiber installiert ist sollte der Brick Viewer den Master anzeigen. Python findest du auf http://www.python.org.

Jetzt hat dein Python was von ctypes gefunden, wo auch immer das jetzt weg kommt Allerdings wurde diese _ctypes.so gegen ein anders konfiguriertes CPython gelinkt. Daher jetzt die Meldung über das fehlende PyUnicodeUCS4_FromEncodedObject Symbol in CPython selber: http://www.rosettacommons.org/node/1901 Mein eindruck ist, dass GNUBLIN ein minimalistisch konfiguriertes Python ausliefert, dem z.B. ctypes und UCS4 fehlen. Ich hab da jetzt auch keinen einfachen Lösungsvorschlag für außer Python neu aus Source zu kompilieren. Keine gute Lösung, wird aber wahrscheinlich funktionieren.

Okay, das hört sich soweit schon mal gut an. Dass heißt auch du hast schon versucht den Treiber zu installieren aber das hat nicht beklappt. Wenn du für das Unbekannte Gerät im Menu "Treiber aktualisieren" klickst, dann sollte ein Fenster kommen in dem Windows fragt ob es bei "Windows Update" nach einem Treiber suchen soll. Das gibt es dann 3 Optionen zur Auswahl, zweimal was mit Ja und einmal Nein. Du musst Nein wählen und Weiter klicken. Im nächsten Fenster fragt Windows dich ob es automatisch nach dem Treiber suchen soll. Hier wählst du die zweite Option für nicht-automatisch Suchen. Im nächsten Fenster kannst du in der Mitte ein Verzeichnis angeben in dem er suchen soll. Hier wählst du das drivers Verzeichnis vom Brick Viewer, in dem die atm6124_cdc.inf Datei liegt und klickst Weiter. Jetzt sollte Windows den Treiber finden und dir noch eine Warnung anzeigen. Da klickst du "Installation fortsetzen". Zu guter Letzt sollte jetzt das Unbekannte Gerät im Geräte Manager verschwunden sein und ein "AT91 USB to Serial Converter" Gerät auftauchen.

Ist korrigiert. Danke für den Hinweis.

Ah, sorry. Ich meinte dmesg und das Log nicht für die letzten Abstürzen, sondern für mögliche zukünftige Logeinträge mit Datum zu versehen ist in git schon passiert und die nächste brickd Version wird es beinhalten. Bis dahin kannst du in config.py das Datumsformat manuell ändern: LOGGING_DATEFMT = "%H:%M:%S" durch LOGGING_DATEFMT = "%Y-%m-%d %H:%M:%S" ersetzen.

Wenn ich mir deinen Code ansehe, dann stimme ich zu, dass du Servo 6 mit dem Poti stellst. Servo 5 fährt auf +90 wenn der Taster gedrückt wird und fährt auf -90 zurück wenn du den Taster wieder loslässt. Soweit so gut, nun zu Servo 4: [...] # Callback function for interrupts def cb_interrupt(interrupt_mask, value_mask): print('Interrupt by: ' + str(bin(interrupt_mask))) print('Value: ' + str(bin(value_mask))) if value_mask & (1 << 0): servo.set_position(5, 9000) else: servo.set_position(5, -9000) servo.set_position(4, 9000) def cb_reached(servo_num, position): if servo_num == 4 and position == 9000: servo.set_position(4, -9000) if __name__ == "__main__": [...] servo.register_callback(servo.CALLBACK_POSITION_REACHED, cb_reached) servo.set_pulse_width(4, 1000, 2000) servo.set_period(4, 19500) servo.set_acceleration(4, 0xFFFF) # Full acceleration servo.set_velocity(4, 0xFFFF) # Full speed servo.enable(4) # enable Servo No. 4 [...] Loslassen des Taster bekommst du in cb_interrupt mit. Dort also Servo 4 nach +90 schicken. Dass Servo 4 +90 erreicht hat kannst du im Position Reached Callback mitbekommen: cb_reached. Wenn Servo 4 +90 erreicht hat ihn nach -90 schicken.

Deine Software speziell libusb ist auf aktuellem Stand. Ich hatte jetzt fast gehofft du hättest eine alte libusb Version und wir könnten der die Probleme in die Schuhe schieben Bezüglich USB Hub. Wir hatten hier mal ein Problem mit einem USB Hub, das sich unter dmesg mit 'USB port xy disabled by hub (EMI?), re-enabling' darstellte. Diese Problem führte auch dazu, dass ein Brick nicht mehr ansprechbar war. Allerdings war er dann auch nicht mehr unter lsusb aufgeführt. Daher wäre es interessant ob unter dmesg irgendwas zu USB steht außer die zu erwartenden Connect und Disconnect Einträge für an- und abgesteckte USB Geräte. Ansonsten ist natürlich weiterhin interessant was im brickd Log steht wenn das Problem auftritt. Sieht das immer so aus wie dein letztes kommentiertes Log? Wir kommen dem Problem schon noch auf die Spur

Windows XP also. Folgende Schritte: 1. Zieh das USB Kabel vom Brick ab. 2. Ruf den Geräte Manager auf: Start -> Systemsteuerung -> System -> Hardware -> Geräte Manager. 3. Wenn du "Anschlüsse (COM und LPT)" aufklappst sollte da dein "Thinkpad Modem" sein. 4. USB Kabel an Brick anstecken. 5. Jetzt sollte unter "Anschlüsse (COM und LPT)" ein weiteres Gerät auftauchen, wahrscheinlich mit einem Ausrufezeichen in einem gelben Kreis gekennzeichnet. 6. Windows sollte jetzt selbst den Treiber dafür finden oder dich fragen. Falls Windows dich fragt ob es bei Windows Update nach einem Treiber suchen soll, dann wählst du 'Nein' und klickst weiter. 7. Jetzt sollte das neue Gerät "AT91 USB to Serial Converter" heißen.

fjahn, eigentlich solltest du den zweiten Treiber der hier erwähnt wurde nicht brauchen. Es sollte so gehen. Aber sag doch erstmal welche Windows Version du da verwendest? Windows XP, Vista, oder 7?

Okay, 1m Bricklet Kabel sind schon die längeren, da du aber nichts ungewöhnliches in der nähe hast würde ich ein EMV Problem hier mal ausschießen wollen. Das Log ist sehr interessant. "Read callback not successful (status 1): Probably disconnect" ist normal wenn du den Brick resettest oder absteckst. Die Meldung hängt mit der Funktionsweise von USB zusammen. brickd schickt für jedes USB Device 5 Read Befehle ab. Diese blockieren dann so lange bis es etwas von USB zu lesen gibt und liefern dann das Gelesene ab. Wenn jetzt der Brick resettet oder abgesteckt wird dann brechen die wartenden Read Befehle mit einen Fehler ab und genau das führt zu dieser Meldung. Das eigentliche Problem mit dieser Meldung um 11:21:48 ist aber, dass sie ohne äußeren Einwirkung in Form von Reset drücken oder Abstecken zu kommen scheint. Das ist verdächtig. Die folgenden "USB context broken, trying to fix it" Meldungen besagen, dass beim Abfragen aller USB Devices des Systems ein Fehler aufgetreten ist und brickd versucht diesen zu beheben, aber scheitert. Warum 6min zwischen "Read callback not successful" und "Removed USB device" vergehen ist mir nicht klar. Im normalen Reset ober Absteck Fall kommen die beiden Medlungen direkt nacheinander. Das du nach einem "Read callback not successful" keine Antwort mehr vom Brick bekommst ist erwartet. So ist das gerade in brickd programmiert. Du kannst das mal testweise ändern, indem du in src/brickd/usb_device.py in Zeile 304 das 'self.alive = False' auskommentierst. Dann wird nach einem solchen Fehler versucht weiterzulesen. else: # TODO: Better error handling logging.warn("Read callback not successful (status " + str(status) + "): Probably disconnect") self.alive = False # diese Zeile auskommentieren per # Da aber danach das "USB context broken, trying to fix it" im Log kommt vermute sich da USB Probleme. Dazu einige Fragen: - Welche libusb Version hast du installiert? Wir verwenden hier 1.0.8. - Welche Linux Kernel Version verwendest du da? - Hast/Hattest du das Problem auch wenn der Master direkt am Rechner angeschlossen ist ohne USB Hub da zwischen?

Ich muss hier auf Ubuntu nc mit -q1 statt -w1 verwenden, da sonst nc die Verbindung zu früh schließt. Ansonsten funktioniert das hier auch so wie erwartet. USB-mäßig sollte das kein Problem sein. Wie lang ist denn das Kabel zwischen Master und Temperature Bricklet? Hast du vielleicht da ein besonders langes Kabel dran? Oder hast du was in der nähe, dass EMV-mässig stören kann, große Motoren oder Neonröhren beim Einschalten etc? Oder fallen die Aufhänger des Master zufällig mit Gewittern zusammen? Gefühlt sollte das kein RAM Problem sein. Neue TCP/IP Connections öffnen ändert hier im Test nichts am RAM Verbrauch von brickd. Das gilt auch fürs Packets schicken zwischen Client, brickd und Brick. Es gibt wie gesagt ein Speicherleak Problem im Zusammenhang mit USB ab- und anstecken. Da bin ich gerade dabei das zu Untersuchen. Aber das kann hier nicht dein Problem sein. Deine Beschreibung, dass du manchmal brickd neustarten musst und manchmal den Master resetten musst damit es wieder geht, deutet für mich darauf hin, dass hier 2 Probleme vorliegen. Eins im Master und eins in brickd. Ich hab das hier gerade nochmal mit borg besprochen und er meint dass kann durchaus sein, dass die Kommunikation des Masters hängt, aber dennoch USB soweit funktioniert dass er in lsusb noch da ist. Dein letztes Log sieht auch exakt wie erwartet aus. Da mir gerade die Ideen ausgehen, hier mal ein Vorschlag der eher in Blau hinaus geht. Falls du die Möglichkeit hast könntest du dein Temperature Bricklet mit diesem Plugin flashen: http://download.tinkerforge.com/_stuff/temperature-bricklet-100khz.bin Diese liest den Temperatur Sensor auf dem Bricklet mit 100kHz statt 400kHz aus.