Loetkolben

Danke fuer deine mutige Antwort. Passt schon. Weiterhin viel Spass beim Experimentieren. Loetkolben

Ich finde die Entwicklung sehr erfreulich! Die Frage von borg "wie" man das machen soll verstehe ich nicht so ganz. Soweit ich das sehe soll unter [de|en].tinkerforge.com/doc die Doku angezeigt werden. Warum nicht, das macht die Wikipedia doch genauso und warum sollte man das Rad neu erfinden? Was gegen ein www.tinkerforge.com/[de|en]/doku spricht weiss ich aber auch nicht. Aus meiner Sicht koennen nur technische Gruende fuer den einen oder anderen Vorschlag sprechen. Der Loetkolben

Das Brakeout Bricklet ist quesi schon ein I2C Bricklet, wobei nur die API fehlt. Aber weiterhin dueftest du dir erstmal ein anderes neues Stueck Hardware zulegen beim dem die Shift Taste ordnungsgemaess funktioniert. Wie mir zu Ohren gekommen ist, nutzt du diese defekte Tastatur auch in anderen Foren. Auch dort haelt sich anscheinend die Begeisterung in Grenzen. Der Loetkolben

Sehe ich nicht so! Aus Usersicht mag das stimmen, aus Tinkerforge Sicht nicht unbedingt! Tinkerforge sollte die Sprache nehmen von der sie sich den groessten wirtschaftlichen Erfolg versprechen! Was nuetzt es mir wenn ich Handmixer fuer Nordkoreas Hausfrauen produziere und die Anleitung in Englisch mache? Tinkerforge hat sich da wohl aus Kapazitaets- und Wirtschaftslichkeitsgruenden fuer Englisch entschieden. Das finde ich OK. Damit auch weiterhin neue Kunden hinzukommen koennen sehe ich ein groesses Potenzial an Leuten die entweder nur deutsch lesen koennen oder aber keine Lust haben sich mit einem Produkt zu beschaeftigen das eine englische Anleitung hat. Aus diesem Grund befuerworte ich eine weitere (kommerziell erfolgreiche) Sprache. Frei nach dem Motto: "Ist die Katze gesund, freut sich der Mensch." Der Loetkolben

Hmmm wirklich nicht? Wenn ich das noch recht in Erinnerung habe, es ist ca. 15 Jahre her, dann waren einige Zeichen (8 oder 16 Stueck) selbst definierbar. Gibt es das nicht mehr? Edit: 10 Sekunden Google: Thread: Diplaying User Defined Graphics on alphanumeric LCD HD44780 LCD User-Defined Graphics Und nu ?? Edit2: Geht doch auch mit diesem Controller. Siehe Doku auf Tinkerforge: Internal Memory - Character Generator ROM (CGROM): 10,080 bits (204 characters´5´8 dots) & (32 characters´5´11 dots) - Character Generator RAM (CGRAM): 64´8 bits (8 characters´5´8 dots) Muesste ggf. nur per API zugaenglich gemacht werden, oder ggf. kann man die Setbefehle schon direkt senden. Da ich kein LCD Modul habe muss ich nu aber passen. Der Loetkolben

Mit gesunden Menschenverstand und antrainierten Marketingverhaltensweisen: Ich stehe von dem Regal mit Dosensuppen. Auf der einen Dose, die in Frage kommt, kann ich die Inhaltsangaben lesen, auf der anderen Dose kann ich es nicht, da ich die Sprache nicht verstehen. A) Ich kaufe die Dose die in Frage kommt mit der Inhaltsangabe die ich verstehe. B) Ich kaufe die andere Dose und Frage im Forum solange bis ich verstanden habe was drin ist. C) Ich kaufe beide Dosen und werde die 2. Sprache lernen D) Ich beschwere mich vor dem Kauf beim Mitarbeiter und erarbeite mit ihm solange die Inhaltsangabe bis ich sie verstanden habe um dann ggf. die Dose nicht zu kaufen. Frage: Was ist die wahrscheinlichste Antwort/Moeglichkeit? Wenn du 1000 Menschen dieses Experiment machen laesst werden alle Moeglichkeiten wohl genutzt werden, denn die Menschen sind unterschiedlich, aber nur eine Antwort traegt zum massgeblichen wirtschaftlichen Erfolg des Unternehmens bei! Also ehrlich: Die Tinkerforgedosen sind nun mal nicht so einzigartig, dass es nicht auch andere technische Spielwaren gibt auf die man ausweichen kann, wenn man das Prinzip nicht versteht. Nochmals: Ich will nur damit sagen, dass aus meiner Sicht eine deutsche Info das Kundeninteresse, bei einer Firma mit dem Kundenstandort Deutschland, deutlich erhoehen wuerde. Eine islaendische (oder fehlende) Uebersetzung nicht. Der Loetkolben

Falsche Betonung! Falsch: "zur Not UNS" Richtig: "zur NOT uns" Man muss schon Not haben um zu Fragen. Besser waere es erst garkeine Fragen aufkommen zu lassen. Der Konsoment greift immer zuerst zu einem Produkt zu dem er meint keine offenen Fragen zu haben. Warum ich es zumindest (ein wenig) ernst meine? Wegen der Ueberschrift des Threads! Ich wuensche Tinkerforge weiterhin viel Erfolg und gutes Gelingen fuer die Produkte! Ich bin der Meinung, dass ein gutes Marketing und die passende Ansprache des Zielpublikums wichtig sind. Da koennte, aus meiner Sicht, noch ein wenig dran gefeilt werden. Ich betone: Aus meiner Sicht! Egoistisch gesehen kann fuer mich alles so bleiben wie es ist. ICH komme mit den Infos klar. Diejenigen die damit nicht klarkommen haben weder das Produkt gekauft noch, sich hierzu im Forum geaeussert! Der Loetkolben

Ja, so etwas finde ich gut, aber der User hat NICHT DIE FREIHEIT ob er die Anleitungen in Deutsch oder Englisch lesen will. Meine Frage dazu: "Warum so stringend?" Der Loetkolben

Keiner hat gesagt, dass es NUR in deutsche sein muss, aber man sollte sich mal die Zielgruppe/Markt genauer ansehen. Also wenn ich dich richtig verstehen sollte der durchschnittliche Tinkerforgekunde des englishcen maechtig sein. OK, dann mein Vorschlag: Alle deutschen Forumsbeitraege werden sofort geloescht. Nur noch englisch ist erlaubt. Fragen: Was bleibt nach 2 Wochen uebrig? Wie viele Kunden springen ab? Wie viele Kunden gewinnt man mit dieser Massnahme? Ist es fuer die Mehrheit hier im Forum nicht EINFACHER deutsch zu lesen und zu schreiben? Wenn du die letzte Frage mit "Ja" beantwortest, muesste es auch bedeuten, dass es einfacher ist die Anleitungen in deutsch zu lesen. Ergo: Je einfacher es ist umso mehr Kunden koennen es verstehen und mitmachen. Also "fordere" ich konsequentes handeln: Entweder alle deutschen Forumsbeitraege streichen oder die Anleitungen auch in deutsch zu veroeffentlichen. Achso: Warum erscheinen seit Jahr(zehnt)en die Programmieranleitungen/Handbuecher/Hilfeseiten fuer Windowsprogrammierwerkzeuge auch in deutsch und anderen Sprachen? Microsoft und Konsorten koennten sich doch auf Englisch beschraenken, da sich so etwas nur an Programmierer richtet. ... Richtig! Die Akzeptanz und damit der Verkauf ist hoeher! Der Loetkolben

Und genau das ist auch ein Kritikpunkt von mir am Webauftritt. Die Produkte sind sehr gut, aber am Marketing fehlt es noch! Ein weiterer Punkt sind die nur auf englisch verfassten Infoseiten. Ein paar wenige beschweren sich hier im Forum, aber man denke an all diejenigen die sich garnicht erst Beschweren und dadurch die Lust am System verlieren. Fuer mich ist es immer wieder erschreckend festzustellen wie wenig Leute des Englischen im allgemeinen, aber auch als ITler, maechtig sind. Oft wird es versucht zu kaschieren, aber es faellt doch haeufig auf. Ich spreche nicht vom Hardcore IT Fachmann, sondern vom durchschnittlichen ITler an den sich auch das Tinkerforge System richtet. Ich glaube das eine deutsche Parallelbeschreibung gut sein wuerden. Dies muesste entsprechend vermarktet werden. Nun warten wir mal ab was so kommt. Was macht eigentlich das Ethernet/WLAN Interface? Der Loetkolben

BTW: Es ist Sommer!

Zwei weitere Ausfaelle gleicher Art. Durch einschalten des entfernt stehenden PC scheint der Ausfall erneut ausgeloest worden sein. Problemloesung wie oben: Brickd stop/start brachte keine Erfolg. Ein Druck auf den Resetknopf des Masterbrick und der Zugriff funktionierte wieder. Die Logfiles schenke ich mir, da keine neue Information dort enthalten sind. Wir folgen der 1. Idee von photron: Masterbrick ohne Hub. Wir werden jetzt an den 2. USB port NUR den Masterbrick stecken. Die Cam wird sich mit dem der SDCard einen Port teilen. Die Lage der Kabel versuchen wir so zu lassen wie sie sind. USB Anschluss bisher: USBPORT1 --- CARDREADER + SDCARD USBPORT2 --- HUB + CARDREADER_inside_HUB + CAM + MASTERBRICK + 1m --- TempBricklet + 1m --- IO4 Bricklet USB Anschluss neu, wobei Masterbrick "solo" am USB Port haengt. USBPORT1 --- HUB + CARDREADER_inside_HUB + SDCARD + CAM USBPORT2 --- MASTERBRICK + 1m --- TempBricklet + 1m --- IO4 Bricklet Der Loetkolben

Hallo photron, danke fuer die Analyse und Hilfestellung. Sehe ich auch so. Ist es die 230V LED Lampe oder die Neonschreibtischlampe oder eine sonstige Spannungsspitzenquelle? ... Am 10.7.2012 gab es den naechsten Ausfall. Kurzzusammenfassung: Brickd stop/start brachte nichts. Ein Druck auf den Resetknopf am Master hat geholfen. Diesmal musste keine Hardware abgestoepselt werden! Einzige Auffaelligkeit: Zwischen 22:00h und 23:00h wurde der "grosse" PC mit "Neon"schreibtischlampe angeschaltet. Er ist ca. 2 Meter entfernt und nur via Ethernet/Switch und Stromleitung mit dem Masterbrick-PC verbunden. Im dmesg waren diesbezueglich keine Eintraege. Die Logs im Detail: # 22:00h Abfrage OK. 2012-07-10 22:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa0990ac> 2012-07-10 22:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-10 22:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-10 22:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-10 22:00:01 <INFO> <usb_device.py:275> Read callback: 1 2012-07-10 22:00:01 <INFO> <brick_protocol.py:74> Callback: 1 2012-07-10 22:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa0990ac> # Zwischen 22:00h und 23:00h wurde der "grosse" PC mit "Neon"schreibtischlampe angeschaltet. Er ist ca. 2 Meter entfernt und nur via Ethernet/Switch und Stromleitung mit dem Masterbrick-PC verbunden. # Abfragen waren nicht mehr moeglich. 2012-07-10 23:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa0990ac> 2012-07-10 23:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-10 23:00:02 <INFO> <usb_device.py:311> Write to device: 1 2012-07-10 23:00:02 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-10 23:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa0990ac> # dto. Keine Abfrage moeglich. 2012-07-11 00:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09916c> 2012-07-11 00:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-11 00:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-11 00:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-11 00:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09916c> lsusb vor dem Druck auf den Masterbrick Resetknopf: PC:/var/log# lsusb Bus 001 Device 010: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub lsusb nach dem Druck auf dem Resetknopf am Masterbrick. Es hat sich nur die GrauTec ID geaendert. Zugriff war sofort wieder moeglich. PC:/var/log# lsusb Bus 001 Device 011: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Hat nun der Hub oder Masterbrick ein Problem? Als naechstes ueberlegen wir den Hub mit Cam (an diesem Port) wegzulassen. Der Loetkolben

Hallo, hier der Nachtrag direkt von der Hardware: Druck auf den Resetknopf am Brick. Das Ergebnis: lsusb Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Kein erfolg also. 2. Druck auf Resetknopf: Gleiches Ergebnis: Kein Erfolg. Masterbrick vom Strom getrennt (Usb Kabel abgezogen und angesteckt): Kein Erfolg. USB Hub (an dem das Masterbrick, die Cam und ein Reader haengen) aus dem USB Port vom PC gezogen und wieder angesteckt. Ergebnis: Alles ok. lsusb Bus 001 Device 010: ID 16d0:063d GrauTec Bus 001 Device 009: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 008: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 007: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Was lernen wir das daraus? Ich weiss es nicht. Ist es der Hub oder der USB Port selbst? Oder wird der Bus nur durch einen externen Event abgeschossen? Dies zur ersten Info. Das Problem wird weiterbeobachtet und ich muss mir erstmal gedanken ueber dieses Ergebnis machen. Der Loetkolben

Hallo photron, so nun bin ich wieder da und kann den Beitrag verfassen. Das Problem ist letzte Woche wieder aufgetaucht. Dabei hat sich sogar ein Teil des USB Busses weggehaengt. Aus der Ferne konnte ich nur den Rechner rebooten, was aber keinen Erfolgt hatte. Der Masterbrick ist trotz zweiter Reboots nicht erreichbar. Ich gehe davon aus, dass ein Druck auf den Resetknopft am Masterbrick das Problem sofort loest. Also der Reihe nach. Das "self.alive = False." ist so eingetragen. So sieht der lsusb normalerweise aus (Kopie aus voherigem Posting): PC:~#lsusb Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Port 2 Bus 001 Device 005: ID 16d0:063d GrauTec Port 2 Bus 001 Device 004: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Port 2 Bus 001 Device 003: ID 14cd:125a Super Top Port 1 Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub Port 2 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Port root Nun /var/log/brickg.log von besagter Problemzeit. In voller Laenge, aber es ist trotzdem ueberschaubar. Normalerweise wird jede Stunde einmal das Temperaturbricklet abgefragt. 2 mal am Tag wird eine 230V LED Lampe via RS232 Schittstelle an und ausgeschaltet. # 5:00h Bricklet Abfrage noch ok. 2012-07-03 05:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b2d0ac> 2012-07-03 05:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:311> Write to device: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:184> Write callback length: 4 2012-07-03 05:00:01 <INFO> <brick_protocol.py:74> Callback: 1 2012-07-03 05:00:01 <INFO> <usb_device.py:275> Read callback: 1 2012-07-03 05:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b2d0ac> # Hier geht das Problem los. Wieder 5:05h. Als die 230V LED Leuchte, via RS232, eingeschaltet wurde. 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect 2012-07-03 05:05:03 <WARNING> <usb_device.py:286> Transfer exception: Probably disconnect 2012-07-03 05:05:03 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:03 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:03 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <usb_device.py:126> Deleting USB device 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:04 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:04 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:06 <WARNING> <usb_notifier.py:90> usb context broken, trying to fix it 2012-07-03 05:05:06 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device 2012-07-03 05:05:09 <INFO> <brickd_linux.py:95> Removed USB device # Hier laeuft die erste Abfrage nach dem Problem um 6:00h in Leere. 2012-07-03 06:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b268ec> 2012-07-03 06:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b268ec> 2012-07-03 07:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b26f6c> 2012-07-03 07:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b26f6c> 2012-07-03 08:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x9b269cc> 2012-07-03 08:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x9b269cc> # PC rebooted. USB devices nicht erreichtbar. Siehe lsusb. 2012-07-03 08:32:08 <INFO> <brickd_linux.py:76> brickd started # Anfrage laeuft ins leere, da USB Devices nicht verfuegbar. Siehe lsusb. 2012-07-03 09:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa562dac> 2012-07-03 09:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa562dac> # PC erneut rebooted 2012-07-03 09:28:08 <INFO> <brickd_linux.py:76> brickd started # Jede Stunde laeuft die Anfrage ins Leere. ... u.s.w. 2012-07-03 10:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa08cdac> 2012-07-03 10:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa08cdac> 2012-07-03 11:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 11:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 12:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 12:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 13:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0xa09206c> 2012-07-03 13:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0xa09206c> lsusb sieht nach dem 1. und 2. Reboot so aus: PC:/# lsusb Bus 001 Device 006: ID 14cd:125a Super Top Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Was nun tun? Ich wuerde gerne nur mal den Resetknopf am Masterbrick druecken und dann schauen on sich die Devices wieder melden oder hast du eine andere Idee? Ich gehe davon aus, das bei einem Reboot des PC die 5 Volt Versorgungsspannung fuer die USB Ports nicht unterbrochen wird (Sicher bin ich mir aber nicht). Das koennte erklaeren warum ein haengender Masterbrick (oder anderes USB Device) auch nach dem Reboot den Bus blockiert. Soll man das Problem mit der installierten Firmware (brickd 1.0.7) weiter versuchen einzugrenzen oder die aktuelle Firmware + brickd aufspielen? Viele Gruesse Der Loetkolben.

Hallo photron, Herzlichen Dank fuer Dein Verstaendniss! So nun habe ich die eine Zeile auskommentiert. Ich bin beim brickd v 1.0.7 geblieben. (Keine 2 Aenderungen auf einmal) Die Datei ist: /usr/share/brickd/usb_device.py Die Zeile ist aber die 281 (nicht 304). Zur Sicherheit: logging.info("Read callback: " + str(type)) else: # TODO: Better error handling logging.warn("Read callback not successful (status " + str(status) + "): Probably disconnect") ##Zeile281 self.alive = False try: transfer.submit() except libusb1.USBError: logging.warn("Transfer exception: Probably disconnect") self.alive = False Nun warten und Tee trinken. Die 100kHz Firmware kann ich im Moment nicht einspielen, wobei diese erste Option erstmal seine Wirkung zeigen kann. Der Loetkolben

Einfach nur mal Danke! Der Loetkolben

Hallo photron, nun war es wieder soweit. Seit 5 Tagen war Ruhe, bzw. alles lief reibungslos. Die letzten Abfragen der Temperaturwerte von heute. Einmal pro Stunde: 20120625_04:00:03;1340589603;23.56 20120625_05:00:04;1340593204;23.56 20120625_06:00:03;1340596803; 20120625_07:00:03;1340600403; 20120625_08:00:03;1340604003; 20120625_09:00:03;1340607603; 20120625_10:00:03;1340611203; /var/log/brickd. Siehe 5:05h!! # 4:00h Abfrage OK. 04:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 04:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 04:00:01 <INFO> <usb_device.py:311> Write to device: 1 04:00:01 <INFO> <usb_device.py:184> Write callback length: 4 04:00:01 <INFO> <usb_device.py:275> Read callback: 1 04:00:01 <INFO> <brick_protocol.py:74> Callback: 1 04:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # 5:00h Abfrage OK. 05:00:02 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 05:00:02 <INFO> <usb_device.py:158> Add callback for message: 1 05:00:02 <INFO> <usb_device.py:311> Write to device: 1 05:00:02 <INFO> <usb_device.py:184> Write callback length: 4 05:00:02 <INFO> <brick_protocol.py:74> Callback: 1 05:00:02 <INFO> <usb_device.py:275> Read callback: 1 05:00:04 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # WIE JEDEN MORGEN um 5:05h wurde durch ein "Avocent PM10*" eine 230V 0,5W LED Lampe angeschaltet. #Das Ding macht (im Moment) nichts anders. Das An/Aus passiert 2 mal am Tag. #Es gab in den letzen Tagen keine Probleme. 05:05:02 <WARNING> <usb_device.py:280> Read callback not successful (status 1): Probably disconnect # Keine Abfrage moeglich 06:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd0cc> 06:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 06:00:01 <INFO> <usb_device.py:311> Write to device: 1 06:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd0cc> # Keine Abfrage moeglich 07:00:01 <INFO> <brick_protocol.py:67> New socket connection: <brick_protocol.BrickProtocol instance at 0x99dd12c> 07:00:01 <INFO> <usb_device.py:158> Add callback for message: 1 07:00:03 <INFO> <brick_protocol.py:71> Connection lost: <brick_protocol.BrickProtocol instance at 0x99dd12c> *) Avocent PM10 PC:~#lsusb Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader Bus 001 Device 005: ID 16d0:063d GrauTec Bus 001 Device 004: ID 046d:09a4 Logitech, Inc. QuickCam E 3500 Bus 001 Device 003: ID 14cd:125a Super Top Bus 001 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub dmesg hat keine USB Eintraege. Letzer dmesg Eintrag 2 Stunden nach dem booten vor 5 Tagen. Mein Ueberlegungen bisher: Es gibt zwei unterschiedliche Weghaenger: Zum einen ist nur das USB Device nicht ansprechbar, zum anderen nur haengt sich der USB Bus weg. Ein Stop und Start des brick hat diesmal geholfen. Ein Resetknopfdruck am Masterbrick war nicht notwendig. Manchmal muss aber auch der Resetknopf gedrueckt werden. Nochmaldruebernachdenk: Letzens ist das Problem zeitlich mit dem Einschalten des "grossen" PC mit Schreibtischlampe zusammengefallen (2m entfernt), diesmal mit dem Einschalten einer winzigen LED Lampe ueber eine professionelle Remotebox direkt in der Naehe. (Ja, da ist ein Ralais drin). Sind die (Bricklet-)Kabel doch Antennen? Ist das evtl. doch ein EMV Thema? Der Loetkolben

Hallo borg, danke fuer die Info. Uijuijui. Dann weiss ich auch warum die Spannung in die Knie geht. Hatte ich nicht irgendwo gelesen, dass jeder IO Port 20ma liefert? Muss ich falsch im Kopf haben Anbei eine Idee: Vorschlag fuer das naechste IO4 Bricklet: Entweder passende Loecher zum nachruesten von (Fingertauglichen) Transistoren und Widerstaenden "einbauen" um LED/Relais/etc anschliessen zu koennen oder ein Lochrasterfeld, welches man "abbrechen" kann wenn es nicht benoetigt wird. Eigentlich baut doch fast jede 2. Applikation auf einen nachgeschalteten Transistor auf. Beim Tippen kommt mir noch eine (alternative) Idee: IO-Port sofort ZUSAETZLICH mit SMD Transistor und SMD Led bestuecken und ueber einen Loetjumper (Loetklecks) "abschaltbar" machen. Damit bleibt der IO Port wie bisher ueber die Klemmen nutzbar und man hat eine Kontrolle ob der Port an oder aus ist. Wenn die Schaltung laeuft entfernt man den Loetpunkt und die LEDs bleiben aus. Rechnet das doch mal durch. Wie viel teurer wuerde so ein IO4 Bricklet? Der Loetkolben

Hallo SierraX, danke fuer die Info. Dann sind das die: LED Weiß, Superhell "LowCost" LED-5-10000W Weiß 20 ° Gehäuseart 5 mm 10000 mcd Technische Daten Typ LED-5-10000W Abstrahlwinkel 20 ° IF 20 mA UF 3.2 V Farbe Weiß Lichtstärke IV 10000 mcd Der Loetkolben

Dazu wollte ich auch schon mal einen Thread aufmachen. Ich habe diese Conrad LED: LED Weiß, Superhell "LowCost" LED-5-18000W Weiß 22 ° Gehäuseart 5 mm 18000 mcd Daten: Technische Daten Typ LED-5-18000W Abstrahlwinkel 22 ° IF 20 mA UF 3.6 V Farbe Weiß Lichtstärke IV 18000 mcd Betreibe die direkt am IO4 Bricklet ohne Vorwiderstand. Hell ja, aber es koennte heller sein. Wenn ich mich recht erinnere lag die Spannung auch gut unter 3.3V Gibt es eine Strombegrenzung am IO4/CPU Port? @SierraX: Welche LED nutzt du? Àrtikelnummer: 181151? Der Loetkolben

Spontanueberlegung: Welcher Chip? Oder Chips? Ist denn schon wieder Fussballzeit? Der Loetkolben

Hallo ArcaneDraconum, das Zauberwort muesste "usbip" sein. Damit koennte man zumindest im Rennen sein. Siehe mal hier:bind_driver -> "--usbip busid make a device exportable" Zum lesen: USB device sharing system over IP network Wenn sein muss : USB/IP Project Wie immer viel Demut und einen langen Atem. Der Loetkolben

Hallo borg, nehme ich auch. Zum testen _ohne Bricklets_ ist das sicher gut geeignet. Der Loetkolben

Thanks for feedback and have much fun with this piece of hardware. :-)) If you more news regarding this toppic please let us know. :-) Der Loetkolben