photron

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.

18:01:02 <INFO> <usb_device.py:311> Write to device: 254 18:01:02 <INFO> <usb_device.py:184> Write callback length: 4 Bis zu dieser Zeile ist das Log exakt wie erwartet unter der Annahme, dass du brickd gestartet hast und der Brick schon angesteckt war. Hier nach sollte die Antwort auf das Enumerate kommen. Denn "Write to device: 254" will dir sagen, dass ein Enumerate Packet (Function ID 254) über USB rausgeschickt wurde. Darauf sollte folgendes für die eintreffenden Antworten im Log stehen (für einen Master mit Temperature Bricklet): 19:53:01 <INFO> <usb_device.py:378> New device Master Brick 1.0 with Stack ID 1 19:53:01 <INFO> <usb_device.py:298> Read callback: 0 253 19:53:01 <INFO> <usb_device.py:378> New device Temperature Bricklet 1.0 with Stack ID 2 19:53:01 <INFO> <usb_device.py:298> Read callback: 0 253 Das ist intern von brickd und passiert für jeden Brick den du ansteckst. Allgemein steht für jedes Packet das über USB rausgeht ein "Write to device" im Log und für jedes über USB eingehende Packet ein "Read callback". Dein Log sagt also, dass in diesem Fall der Master nicht geantwortet hat. Das heißt auch, dass du den Master nicht remote Resetten kannst denn er reagiert ja schon auf ein Enumerate nicht mehr. Was hier genau das Problem ist ist mir leider nicht klar. Wie liest du die Temperatur denn aus, machst du für jede Anfrage eine neue IPConnection auf etc? Ich denke wir werden nicht drum herum kommen, das hier mal versuchen nachzustellen um das Problem zu reproduzieren.

Okay, das ist schon der Treiber. Der hier besteht nur aus der Konfigurationsdatei atm6124_cdc.inf. Da Windows standardmäßig die Erweiterung bekannter Dateitypen nicht anzeigt siehst du diese nur als atm6124_cdc. Im Kontextmenu für diese Datei findet sich ein "Installieren" Eintrag. Also Rechtsklick im Explorer auf diese Datei und "Installieren" wählen, dann ist der Treiber auch schon installiert und wenn du jetzt deinen Master ansteckst sollte er als "AT91 USB to Serial Converter (COM3)" im Geräte Manager auftauchen.

Du sagst die blaue LED auf dem Master neben dem Reset Knopf hat am Anfang geleuchtet wenn du ihn an USB ansteckst. Aber jetzt leuchtet sie nicht mehr. Das deutet darauf hin, dass du aus Versehen die Firmware gelöscht hast. Das passiert wenn du den Erase Knopf gedrückt hältst und ihn dabei per USB anschließt. Dies kann auch im angeschlossenen Zustand passieren wenn du den Erase Knopf gedrückt hältst und dabei den Reset Knopf drückst. Wenn das der Fall ist, dann ist der Master jetzt im Bootloader und du musst die Firmware neu flashen. Ein Brick im Bootloader taucht nicht mehr als USB Gerät auf, sondern als Serielle Schnittstelle (COM Port). Das kannst du im Geräte Manager kontrollieren, dort sollte eine Serielle Schnittstelle auftauchen und verschwinden, wenn du den Master an- und absteckst. Wenn du den "atm6124_cdc.inf" Treiber aus dem drivers Verzeichnis im Brick Viewer Installationsverzeichnis schon installiert hast, dann sollte im Geräte Manager ein "AT91 USB to Serial Converter (COM3)" auftauchen, wenn du den Master per USB anschließt. Wobei die Zahl hinter dem COM davon abhängt wie viele Serielle Schnittstellen dein Rechner schon hat. Jetzt kannst du im Brick Viewer den Master neu flashen, so wie borg das schon beschrieben hat. Du meintest du würdest "Could not connect to Brick: No brick in SAM-BA mode found" als Fehler bekommen. Das kann passieren wenn du die falsche Serielle Schnittstelle im "Flashing" Fenster für "Serial Port" ausgewählt hast. Ich schätze du hast dort in der Dropdownbox mehrere zur Auswahl und musst nur die richtige wählen bevor du "Save" klickst. Dann sollte das funktionieren. Wie gesagt sollte die richtige Schnittstelle "AT91 USB to Serial Converter (COM3)" oder so ähnlich heißen. Nach dem das Flashen fertig ist musst du den Master per Reset Knopf oder ab- und anstecken neustarten. Jetzt sollte die blaue LED wieder leuchten und der Master im Brick Viewer wieder auftauchen.

Das einzige Debian Packet mit ctypes im Namen, das ich finden kann ist das hier http://packages.debian.org/squeeze/python-ctypeslib und das ist nicht ctypes selbst sondern ein Codegenerator basierend auf ctypes. ctypes ist seit Python 2.5 in der Standard Library von Python enthalten. Hast du vielleicht kein Python 2.5, sondern etwas älteres? Testbar per python --version

Die Behandlung fragmentierter Packets ist in den aktuellen Versionen aller Bindings (C/C++ 1.0.11, C# 1.1.4, Java 1.0.10, PHP 1.0.5, Python 1.0.13, Ruby 1.0.2) korrigiert.

Die Checkbox ist gefixed.

"Delphi" Bindings sind als nächstes geplant: http://www.tinkerforge.com/doc/Timeline.html Diese sollen dann natürlich nicht Delphi spezifisch sein sondern mit möglichst vielen Pascal Dialekten, Varianten und Compilern funktionieren, u.a. auch mit FPC/Lazarus. Zu nmap: 'nmap localhost' testet wohl nur die unteren 1024 Ports. Mit expliziter Angabe des Ports zeigt nmap diese als offen an: nmap -p 4223 localhost Der für Bindings interessante Code findet sich nicht direkt in BrickV. Unsere Bindings finden sich in einem eigenen git Repository https://github.com/Tinkerforge/generators Dort gibt es für jeden Brick und Bricklet eine Config Datei die dessen API beschreibt und für jede unterstütze Programmiersprache ein Python Script das aus den Configs die Bindings und die Dokumentation generiert.

Du mischt da definitiv verschieden Bindings Version. Deine ip_connection.h kommt aus Version 1.0.6 oder älter und dein brick_imu.c kommt aus Version 1.0.7 oder neuer. Dass das nicht richtig funktionieren kann, wenn du da einfach dem struct ein Feld hinzufügst ist eigentlich klar Stell mal bitte sicher, dass du alle Dateien aus einer Bindings Version verwendest und am besten dann auch die neuste: http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_1_0_10.zip

Also hier funktioniert das mit /TP auf Projektebene setzen. Zu dem function_id Fehler: Mischt du ip_connection.h und brick_imu.c aus verschiedenen C/C++ Bindings Versionen?

Sicher bleibt das Open Source, wie alles hier. Du kannst alle Software hier finden: https://github.com/Tinkerforge Der Bindings Generator im speziellen ist hier: https://github.com/Tinkerforge/generators

Wir verwenden C nach C99 Standard, Visual Studio kann aber nur C89. Daher musst du Visual Studio sagen den Code als C++ zu kompilieren. Wie das geht steht hier am Ende: http://www.tinkerforge.com/doc/Software/API_Bindings.html#c-c

Committed ist (soweit ich das sehe) der Speicher den die Prozesse wirklich angefordert haben. Aber das ist nicht der Speicher den sie wirklich auch belegen. Daher kann das auch mehr sein als RAM und Swap zusammen gerade belegt sind. Committed ist also nicht der richtige Wert zur Beurteilung des Speicherverbrauchs von brickd. Dazu solltest du dir das Resident Set (RSS) von brickd ansehen. Das Resident Set ist der Teil des Virtuellen Speichers eines Prozesses der wirklich im physikalischen RAM liegt. Zusätzlich solltest du auch noch den Swap Wert des brickd Prozesses ansehen. Beides ist unter /proc/<brickd PID>/status als VmRSS und VmSwap zu finden. Bei mir liegt VmRSS + VmSwap bei ca. 15MB und steigt bei jedem Brick Reset oder neu verbundenen Brick um ein paar kB. Ja den Übergang meine ich. Und ich habe gesagt, dass mir die grüne Linie komisch vorkommt, "denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen." 15MB kamen mir zuviel vor, aber ich habe die Achse falsch gelesen und der Sprung zwischen 6 und 7 ist nur 7MB hoch. Aber dennoch ist mir das komisch, denn ich kann das hier nicht reproduzieren. Solange es läuft ist doch gut, lass es laufen Es gibt noch ein potentielles Problem in den Bindings, dass wenn Packets nicht in einem Stück ankommen sie nicht richtig behandelt werden, was aber im allgemeinen nicht passiert. Diese habe ich in brickd Version 1.0.7 behoben und werde es in den nächsten Tagen auch in allen Bindings beheben.

Ich hab mir deine Lua Bindings gerade angesehen und das sieht sehr gut aus Ich würde hier ähnlich vorgehen wollen wie bei den Delphi Bindings. Hier hat Nic schon die Vorarbeit geleistet und die IPConnection implementiert und einige Bricks und Bricklets. Auf dieser Basis werde ich Delphi Bindings in unser Bindings Generator System einbauen. Ich würde also aufbauen auf deine manuell geschriebenen Bindings unser Bindings Generator System für Lua erweitern wollen, wenn du da nichts gehen hast

Loetkolben, mir ist bei deiner Munin Speicher Grafik nicht ganz klar was die grüne Linie darstellt und welche Achsenskalierung dazugehört. Denn das Anschließen eines Bricks wird keine 15MB Speicher extra brauchen. Ja, brickd 1.0.7 belegt im Moment bei jedem Anschließen eines Bricks so ca. 100kB mehr Speicher. Da ist also ein Memoryleak. Ich bin dem ganzen aber auf der Spur. Was deinen Eindruck mit mehr "unused" Speicher nach der Installation von brickd 1.0.7 angeht, so sieht das für mich einfach nach Flushen des Filesystem Caches in deiner Grafik aus.

Im Prinzip gibts config.py auch auf Windows, allerdings ist es nicht als editierbare Datei verfügbar, wenn du Brick[dv] per Installer installierst. Bessere Konfigurierbarkeit des Loggings und einfaches Ablesen der Versionsnummer sowie Dokumentation des ganzen steht auf der Todoliste

Loetkolben, brickd schreibt ein Log unter /var/log/brickd.log. Allerdings landen da standardmässig nur Errors. Das Log Level kannst du in src/brickd/config.py einstellen. LOGGING_LEVEL = logging.DEBUG aktiviert alle Log Ausgaben. Wenn du brickd per Debian Package installiert hast findet sich die Datei unter /usr/share/brickd/config.py