Jump to content

photron

Administrators
  • Gesamte Inhalte

    3.034
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    39

Alle erstellten Inhalte von photron

  1. Ist auf der Seite des Distance IR Bricklet verlinkt: http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung Wobei GP2D120 (alter Sensor) und GP2Y0A41 (neuer Sensor) beide die gleiche Kalibrierung verwenden. Ich habe da jetzt mal den Eintrag auf geteilt und die 2D120.txt nochmal als 2Y0A41.txt hochgeladen, damit das einfacher zu finden ist.
  2. AddDevice wird entfernt, damit fällt dann auch die Versuchung weg ein Device Objekt gleichzeitig mehreren IP Connections hinzuzufügen, was nicht funktioniert. Was CheckDevice() für NO_RESPONSE tun würde kann jetzt schon jeder Getter und in neuen Protokoll auch jeder Setter wenn die R Option gesetzt ist. VERSION_MISMATCH funktioniert so nicht und hätte nur im alten Protokoll auf per-Funktionsbasis gut funktioniert, da der Check Zustand braucht, wenn man nicht vor jedem Aufruf den Brick erst nach seiner Firmwareversion fragen will. Damit ist die angedachte NotSupportedException leider gestorben. Das Problem mit Funktionen, die die Firmware noch nicht kennt, wird jetzt auf dem Brick robust behandelt und unbekannte Funktions ID führen nicht mehr zu einem Absturz des Bricks, sondern werden ignoriert. Für per-Brick "enumerate" wird jedes Device eine GetIdentity Funktion haben, die die gleichen Informationen wie der Enumerate Callback zurückgibt. GetIdentity wird auch die bisherige GetVersion Funktion ersetzen, wobei GetIdentity im Gegensatz zu GetVersion die Informationen nicht zwischenspeichert und dadurch stateless ist. GetIdentity erlaubt es dann auch die Checks die vorher AddDevice gemacht hat zu realisieren: ushort deviceIdentifier; BrickMaster master = new BrickMaster("UID", ipcon); master.GetIdentity(..., deviceIdentifier); if (deviceIdentifier != BrickMaster.DEVICE_IDENTIFIER) { // report/handle mismatch } Die Änderungen sind auch hier beschrieben: http://www.tinkerforge.com/doc/Protocol_20.html#general-api-changes
  3. Das GPS Modul gibt die Dilution of Precision (DOP) aus. Darüber kann man etwas über die Genauigkeit der Position aussagen. Besser ist wohl aber noch der Estimated Position Error (EPE) in Metern. Diesen gibt das Modul auch aus. Der sagt aber nichts über die höhe aus. Über die Genauigkeit der Höhe kannst du wohl etwas aus dem PDOP (Positional Dilution of Precision) Wert ableiten, der sich auf die 3D Position bezieht.
  4. Da hast du Recht. Das mit dem Port hat mich auch stuzig gemacht und ich habe gerade ein wenig geprueft und einen Nebenkriegschauplatz gefunden. Der brickd fuehrt uns hier hinters Licht. Siehe hier: #reboot ~~~ Pause ~~~ #uptime up 2 min #/etc/init.d/brickd start Starting Brick Daemon: brickd. #/etc/init.d/brickd stop Stopping Brick Daemon: start-stop-daemon: warning: failed to kill 1039: No such process #ls -l /var/log/brickd.log -rw-rw-rw- 1 root root 710 25. Okt 19:05 /var/log/brickd.log #Mit bekanntem Inhalt. und nun Du? Das Problem erkennen wir beide! Nach dem Reboot ist bereits ein brickd gestartet worden. DUMMERWEISE kann man aber nochmals einen brickd starten. Hier mit der PID 1039. Der bricht aber ab (ohne das man es sieht), schreibt das Logfile und setzt noch die KILLPID auf 1039. Welche PID der brickd hat, der beim reboot gestartet wurde ist nicht bekannt. Ein "/etc/init.d/brickd stop" versucht nun PID 1039 zu stoppen. Diesen Prozess gibt es aber nicht. DESHALB habe ich das Logfile falsch interpretiert. Sorry. # ps -ef|grep brickd root 890 1 0 19:03 ? 00:00:01 python /usr/share/brickd/brickd_linux.py Das ist der brickd mit der PID 890 der nach dem reboot automatisch gestartet wurde. Deshalb: Bitte den brickd ueberpruefen lassen ob schon ein brickd laeuft und dann garnicht erst versuchen eine 2. Instanz zu starten die dann die KILLPID umsetzt. -> "brickd already running with PIDxxx" Edit: Gerade installiert: Der brickd 1.0.10 verhaelt sich genauso. brickd 1.0.11 behandelt diesen Fall jetzt richtig und auch das Debian Package stoppt jetzt den alten brickd bevor es einen neuen installiert.
  5. Brick Daemon 1.0.11 Don't broadcast GetStackID responses, avoids confusing clients Update libusb-1.0.dll to support the 2nd generation of Renesas USB 3.0 controllers Lock the PID file on Linux to prohibit starting multiple instances Downloads: Windows, Linux, Mac OS X
  6. Brick Daemon 1.0.11 Die Antwort für GetStackID wird nicht länger per Broadcast versandt libusb-1.0.dll aktualisiert um die 2. Generation des Renesas USB 3.0 Controllers zu unterstützen PID File unter Linux als Look File verwendet um das Starten mehrerer Instanzen zu verhindern Downloads: Windows, Linux, Mac OS X
  7. In der Dokumentation und in der nächsten brickv Version wird darauf hingewiesen wie es sich mit dem Power Mode verhält.
  8. Also Master Brick (Firmware 1.4.6) mit WIFI Extension, Barometer Bricklet (Plugin 1.1.2) versorgt über Step-Down Power Supply. Mit brickv darauf verbunden und seit 1,5 Stunden den Barometer Tab offen und es funktioniert einwandfrei. Tust du da noch was anderes? Verwendest du andere Firmwareversionen? Nachtrag: Barometer Bricklet Plugin Version auf 1.1.2 korrigiert.
  9. Die Höhe wird über die Luftdruckdifferenz bestimmt. Der Referenzluftdruck gegen den die Differenz berechnet wird kannst du im Brick Viewer auf dem Barometer Tab bei "Referenz Air Pressure" einstellen. Standardmäßig wird da 1013,25mbar verwendet, dass ist der Standardluftdurck auf Meereshöhe. Da sich jetzt aber der wirkliche Meereshöhenluftdruck für deinen Ort auch ständig wetterabhängig ändert ist diese "absolute" Höhenberechnung auch wetterabhängig. Das das um 100m daneben liegen kann ist normal. So verhält sich der Luftdruck. Dass das über längere Zeiträume (im Bereich mehrere Minuten) um 2m schwankt ist schon viel aber noch nicht ungewöhnlich. Kurzfristig sollte die Höhe nur im 5-10cm Bereich schwanken. Wenn du beim "Referenz Air Pressure" 0 einträgst und dann "Set" klickst setzt das Bricklet intern den Referenzluftdruck auf den gerade gemessenen Luftdruck. Dadurch wird auch die Höhe auf 0 gesetzt, da die Luftdruckdifferenz dann 0 ist. Da sich aber der Luftdruck ständig ändert schwankt de Höhenberechnung natürlich weiterhin und kann sich auch auch über den Tag hinweg um mehrere 10m ändern. Fazit: Dein Bricklet funktioniert richtig und Luftdruck verhält sich so.
  10. Nein, die Bricks erkennen beim Neustart was wo angeschlossen ist. Das einzige was es in diese Richtung gibt ist, das brickd standardmäßig nicht Callbacks an alle verbundenen IP Connections weiter gibt, sondern nur an die die vorher GetStackID aufgerufen haben, dies passiert aber automatisch in allen Bindings. Das betrifft dich hier aber nicht und das wird auch mit Protokoll Version 2 anders, da wird da brickd und das Protokoll an sich stateless machen werden so dass es robuster wird.
  11. Damit ich sehen kann ob das Bricklet wirklich die neue FW hat. Hmm lass mich mal ueberlegen. ... Wuerde nach einem flashen des Bricklets der Brickviewer die neuen Firmwarestaende automatisch einlesen sobald sich der Masterbrick mit dem brickd wieder verbunden hat? Ne, oder? Doch genau so passiert das. Wenn du den Brick durch den Reset Knopf in brickv, oder per Reset Knopf auf dem Brick selbst oder durch Ab- und Anstecken des USB Kabels neustartet, dann sieht das für brickd und brickv immer gleich aus. Der Brick verschwindet als USB Device und taucht dann kurze Zeit später wieder als USB Device auf. brickd weiss nicht, dass das der gleiche Brick ist und das braucht er auch nicht. brickd und brickv cachen da nichts. brickv bekommt das Reset/Abstecken durch ein enumerate mit is_new=false mit und das Neuauftauchen als enumerate mit is_new=true. Dann liest brickv auch die Versionsinformationen neu aus. Das heißt in deinem Fall reicht ein Reset des Bricks aus. Du musst nicht neu zu brickd verbinden. Dennoch würde ich gerade dein Reconnect Problem verstehen und beheben. Nur ist mir hier gar nicht klar wie ein Reconnect zu brickd dazu führt, dass der Brick auf USB Ebene ein Problem hat und verschwindet. Komplettes brickd.log. Es ist kein Debugging eingeschaltet. Wenn ich das richtig sehe kommen diese Meldungen und vom reboot der Maschine als der brickd versuchte sich zum Brick zu connecten. Ein "/etc/init.d/brickd start" erzeugen die gleichen Meldungen nochmal. Traceback (most recent call last): File "/usr/share/brickd/brickd_linux.py", line 157, in <module> brickd.daemonize() File "/usr/share/brickd/brickd_linux.py", line 145, in daemonize self.start() File "/usr/share/brickd/brickd_linux.py", line 85, in start reactor.listenTCP(config.PORT, BrickProtocolFactory()) File "/usr/lib/python2.6/dist-packages/twisted/internet/posixbase.py", line 419, in listenTCP p.startListening() File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 855, in startListening raise CannotListenError, (self.interface, self.port, le) twisted.internet.error.CannotListenError: Couldn't listen on any:4223: [Errno 98] Address already in use. Nein, das hat nichts mit dem Brick oder USB zu tun. Das Problem hier ist das brickd versucht den TCP/IP Socket auf Port 4223 zu öffnen und jemand auf diesem Port schon einen Socket offen hat. Wahrscheinlich läuft schon ein brickd und du versuchst noch einen zu starten?
  12. Antwort zwischendurch. Nein. Es kann sein, dass von einem Server ausserhalb die Sensoren per Cron (TCP/netcat) abgefragt werden. Alle 10 Minuten ein Request, also kein Dauerrequest. Ein Enumerate wird nicht durchgefuehrt. Okay, ich hätte jetzt gehofft du hättest genau das Problem das ich im Rahmen der Vorbereitung für die Elektor Live gefunden und behoben habe. Das Problem war das wenn 2 Clients/Bindings recht zeitgleich ein GetStackID für das gleiche Device ausgeführt haben, dass ihre intern Datenhaltung dann durcheinander geraten ist. Da GetStackID ein Braodcast ist wird auch die Antwort an alle geschickt und beide Clients bekommen die Antwort zweimal. Das kann dann u.a. dazu führen, dass der Brick in brickv nicht angezeigt wird, da brickv dadurch beim Aufzählen des Bricks eine Exception bekommt. Dieser gleichzeitige Aufruf von GetStackID für das gleiche Device kommt typischerweise durch die Verwendung von Enumerate zustande. Da das bei dir aber nicht der Fall ist und du auch nicht von 2 Clients GetStackID aufrufst hast du noch ein anderes Problem Erinnert mich daran, dass ich die korrigierte brickd Version releasen sollte. Kommt morgen
  13. Okay, ignoriere erstmal alles was ich da noch gerade gefragt habe und beantworte mir die nächste Frage zu erst. Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0 Hast du in diesem Aufbau noch ein weiteres Programm neben brickv, dass gleichzeitig mit brickd verbunden ist und mit enumerate arbeitet?
  14. Welche brickd Version ist das? Warum reconnectest du hier? Das ist ja hier nicht notwendig. Die Verbindung um die es da geht, ist die TCP/IP Verbindung zu brickd, nicht die USB Verbindung von brickd zum Master Brick. Hab das hier gerade nachgestellt und es funktioniert wie erwartet. Und was meinst du mit "weg"? Wird der Brick nicht mehr in brickv angezeigt? Wenn du erneut reconnectest taucht er dann wieder auf? Gibt es eine Exception in brickv? Kennt lsusb ihn noch? Was sagt das brickd Log dazu? Beim Connect broadcastet brickv einen Enumerate Request an alle und dann noch ein GetStackID an alle Devices die Enumerate aufzählt. Ich sehe nicht warum das ein Problem wie das hier erzeugen sollte. Welche Kommunikation? Welche Versionen? Firmware, brickd oder brickv? Reset und (Dis)connect sind zwei sehr verschiedene dinge für einen Brick. Der Brick an sich hat mit dem (Dis)connect zu brickd nichts zu tun! Nein, da das nichts mit einander zu tun hat und das auch nicht sinnvoll ist im Allgemeinen.
  15. Standa hat recht die Geräusch sind unbedenklich, wohl aber unschön. Du könntest im Stillstand einfach den Stepper Brick disablen. Wenn das in deinem Fall nicht möglich ist, weil der Motor aktive eine Position halten muss dann kannst du versuchen den Decay Modus passender zu deinem Motor einzustellen. Standardmässig wird Fast Decay verwendet, das ist die sichere Variante. Es gibt im Brick Viewer keinen Regler für den Decay Modus da es bei großen Motoren bei "falschem" Decay Modus zur Überhitzung und Zerstörung des Bricks kommen kann. Mit 1,2A hast du da aber einen Motor bei dem du ohne Problem mit dem Decay Modus experimentieren können solltest. Dazu musst du dann allerdings dann dein eigenen Programm schreiben und über die SetSyncRect Funktion des Stepper Bricks die Synchrongleichrichtung aktivieren und kannst dann über SetDecay zwischen Fast, Mixed und Slow Decay einstellen.
  16. Es gibt Hot, Warm, Cold und Full Cold Start. Je kälter desto weniger zwischengespeicherte Daten wie die Satellitenflugbahnen und die Uhrzeit werden nach dem Neustart wiederverwendet. Mit Enums für Magicnumbers geb ich dir recht und setzte es mal auf die TODO Liste. Dass get_date_time ein DateTime-Objekt zurück gibt wird allerdings nicht passieren in absehbarer Zeit. Da ist das Feld der Möglichkeiten einfach zu groß als das man das im Generator sinnvoll unterbringen könnte.
  17. Wir haben noch mal das GPS Modul gewechselt. Das neue Modul bekommen wir dann auch mit einem Binärprotokoll, das einfacher zu parsen ist. Dadurch ist jetzt auch wieder Platz freigeworden und wir könne GetStatus aufteilen, wie das hier schon vorgeschlagen wurde. Die aktuelle API ist hier zu finden: http://www.tinkerforge.com/doc/Software/Bricklets/GPS_Bricklet_C.html Neben der Aufteilung von GetStatus gibt jetzt GetCoordinates auch den Estimated Position Error (EPE) zurück.
  18. skippi, dass brickd Problem haben kann wenn ihm der RAM ausgeht kann ich verstehen. Warum da aber irgendwie das Neuflashen von Bricks einen Effekt haben soll sehe ich nicht.
  19. Hast du denn das Bricklet neugeflashed?
  20. Alle Bricklets funktionieren an allen Ports aller Bricks. Da gibt es keine Einschränkungen. Da das Problem hier durch neu Flashen des IO-4 Bricklets gefixed wurde, würde ich vermuten, dass das im EEPROM des Bricklets gespeicherte Plugin eine Macke hatte. Das würde auch erklären, warum das Problem an 2 Master Bricks auftrat. Warum es dann nur am Master Brick und dann auch noch von Port und der Extension Konfiguration abhängt ist nicht klar. WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere Firmware verwendet?
  21. Die Kalibrierung für den Sensor wird im EEPROM auf dem Bricklet gespeichert. Die kannst du mittels Brick Viewer ändern, siehe: http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung-speichern
  22. Die MSDN Knowledge Base sagt, dass Windows 8 und Windows 7 (seit Mai 2012) automatisch den passenden Treiber installieren können, wenn ich das USB Gerät korrekt als WinUSB kompatible ausgibt. Wir verwenden WinUSB über libusb, daher sollte das gehen. Ich habe das testweise funktioniert und der Brick sollte sich jetzt als WinUSB kompatible ausgeben können. Leider funktioniert das noch nicht so richtig wie es soll. Bis dahin kann ich dir den WinUSB Driver Installer Zadig von den libsub Entwicklern als Lösung anbieten. Dieser kann unter Windows 8 einen passenden und signierten Treiber installieren. http://download.tinkerforge.com/_stuff/zadig_v2.0.1.159.exe Wenn du das startest sollte das etwa so aussehen: Wichtig ist dabei, dass das richtige Device ausgewählt ist (hier 'Master Brick') und WinUSB als Treiber. Dann 'Install Driver' klicken. Möglicherweise musst du dann noch einmal den Brick ab und wieder anstecken, damit er dann erkannt wird.
  23. Ich kann das Problem hier reproduzieren. Eine Lösung ist in Arbeit.
×
×
  • Neu erstellen...