photron

Brick Viewer 1.1.14 Bricklet Flashing bricht jetzt beim ersten Verifikationsfehler ab Hinweise für den WIFI Power Mode verbessert UID Format wird überprüft bevor neue UID auf das Bricklet geschrieben wird Erkennung der Industrial Bricklets Plugins auf tinkerforge.com korrigiert Text auf den Knöpfen des Dual Relay Bricklet Plugins von Zustand auf Aktion geändert Monoflop Behandlung für Industrial Bricklets verbessert Downloads: Windows, Linux, Mac OS X

Ein Callback kann nur eine Konfiguration haben. Dass heißt, der Distance Reached Callback kann entweder für < 100 mm oder > 700 mm konfiguriert werden. Du kannst es natürlich auch so konfigurieren, dass der Callback ausgelöst wird wenn die Distanz zwischen 100 und 700 mm liegt oder außerhalb des 100 und 700 mm Bereichs. Insgesamt kannst du nur eine Bedingung für den einen Callback definieren. unregister_callback gibt es: register_callback(id, NULL)

Richtig, das Problem betrifft hier im speziellen C. Zum Beispiel in Python kann man da eine Closure verwenden um der Callbackfunktion Kontext mitzugeben. In C funktioniert das nicht. Da wir ihm Rahmen von Protokoll 2.0 eh API brechen werden, werden wir auch ein user_data Parameter für die register_callback Funktion hinzufügen.

Es funktioniert jetzt, dass ich ein Brick als WinUSB kompatibel ausgibt und Windows 8 dadurch von sich aus den passenden Treiber installiert. Dadurch kann man dann in kürze Bricks anstecken unter Windows 8 und sie funktionieren ohne weiteres Zutun, wie man das z.B. von USB Sticks kennt

Wie in diesem Thread bereits erwähnt kann Windows 8 selbst den passenden Treiber auswählen, wenn sich das USB Gerät passen als kompatibel ausgibt. Ich habe das jetzt zum Funktionieren gebracht für die Bricks. Dadurch wird in kürze keine extra Treiberinstallation mehr nötig sein auf Windows 8. Man kann einen Brick dann einfach anstecken und er funktioniert, wie man das z.B. von USB Sticks kennt

Richtig, unter Windows 8 kann man standardmässig nur noch signierte Treiber installieren und der Treiber der Brick Daemon beiliegt ist nicht signiert. Der Zadig Treiberinstaller von den libusb Leuten kann aber den passenden Treiber signiert installieren. Nic, ich geben dir recht, dass muss auf der brickd Treiberinstallationsseite erwähnt werden. Das Problem ist hier im Forum schon bekannt, ich bin dann aber irgendwie nicht dazu gekommen es ordentlich zu dokumentieren. In Zukunft (wahrscheinlich im Rahmen von Protokoll 2.0) sollen die brickd und brickv Installer die Treiber die sie mitbringen auch gleich installieren und im Falle von Windows 8 auch die signierte Version. Nachtrag: Dokumentation hat jetzt einen Abschnitt über Windows 8.

Ja, ein Brick im Bootloader und ein geflashter Brick sind für das Betriebssytem zwei verschiedenen Geräte, die auch zwei verschiedene Treiber verwenden. Ein Brick im Bootloader ist eine serielle Schnittstelle (die über ein USB Gerät ins System gekommen ist). Ein geflashter Brick ist ein normales USB Gerät, das ein Custom Protokoll spricht.

Einen Brick flashen und mit dem Brick normal über den Brick Viewer arbeiten sind zwei verschiedenen Dinge, die zufällig im gleichen Programm sind.

Das kann mehrere Ursachen haben: 1) Leuchtet die blaue LED neben der USB Buchse auf dem Servo Brick wenn USB angeschlossen ist? 2) Wird der Brick im Geräte Manager richtig angezeigt? Da sollte kein gelbes Ausrufezeichen oder ähnliches angezeigt werden. Hast du den Treiber aus dem drivers Verzeichnis, dass brickd beiliegt installiert?

mb_convert_encoding wird hier benutzt um den String nach UTF-32LE zu konvertieren. Aus UTF-32LE kann ich dann die eigentlichen Unicode Codepoints ausrechnen. Dabei lasse ich PHP mit der auto option raten/ermitteln in welchem Encoding deine .php Datei und damit der "test äöüß" String ist. Das Problem hier scheint zu sein, dass PHP nicht in der Lage ist das in deinem Fall zu bestimmen. Die Encodings die PHP unterstütz sind hier aufgelistet http://www.php.net/manual/de/mbstring.supported-encodings.php Du kannst jetzt versuchen deine .php Datei mit einem anderen Encoding zu speichern, bzw. auto hier mb_convert_encoding($string, "UTF-32LE", "auto") zum Encoding deiner .php Datei ändern.

Das kann eigentlich kein Softwareproblem sein, daher sollte das mit dem Flashen nichts zu tun haben. Die andere Software war wahrscheinlich SAM-BA von Atmel. Die haben wir zum Flashen verwendet bevor wir das in den Brick Viewer eingebaut haben. Das hört sich eher nach einem Hardwareproblem an. Testest du denn beide Master Bricks an der gleichen Stromversorgung, also gleichen USB Port am Rechner oder gleiches USB Netzteil etc? Nicht dass das Problem die externe Stromversorgung ist.

<?php $relais = $dr->getState(); if ( $relais['relay1'] == true ) { $status = "Relais 1 ist geschaltet"; echo "$status \n"; } ?> Wie der Inhalt der Arrays ist wenn die Funktion mehrere Werte zurück geben steht nicht in der PHP Dokumentation. Habs mir auf die TODO Liste gesetzt, das zu verbessern

Der brickd kann deshalb robust einen Disconnect erkennen und ein Enumerate dafür auslösen, weil ihm das Betriebssystem sagen kann, dass ein USB Gerät abgezogen wurde. Bei WIFI und Chibi ist das anders: Wenn du da den Brick außer Reichweite bringst oder ihn von der Stromversorgung trennst dann kann er nicht mehr auf Anfragen antworten. Der Brick hat ja auch keine Chance Bescheid zu sagen, dass er disconnected wurde. Bei TCP/IP passiert da dann nichts weiter, dass erlauben würde aus diesem "der Brick antwortet gerade nicht" irgendwie zu erkennen, dass er auch nicht mehr antworten wird. Die TCP/IP Verbindung wurde ja vom Brick aus nicht aktiv geschlossen, also ist sie noch offen, es werden nur im Moment keine Daten gesendet. Das einzige was da bleibt, ist Timeouts als Indikator für eine funktionierende Verbindung zum Brick zu verwenden.

Ich hab die Beschreibung erweitert. Es geht darum, dass ein Brick (neu-)gestartet wird und daher noch nicht konfiguriert ist, bzw. durch den Neustart seine Konfiguration verloren hat (z.B. die PWM Einstellung eines Servo Bricks). Damit dieser Zustand robust vom Programm erkannt werden kann sendet der Brick von sich aus ein Enumerate Callback (mit enumerate_type connected), für jede neu erstellte Kommunikationsverbindung wie, USB, TCP/IP über WIFI oder Ethernet Extension usw. Damit das auch bei TCP/IP über WIFI oder Ethernet Extension richtig funktioniert muss die Enumeration Callback Funktion gesetzt sein bevor die Verbindung zum Brick aufgebaut wird, da der Master Brick für jede neu eingehende TCP/IP Verbindung einen Enumerate Callback an diese schicken wird. Dabei kann es passieren das ein Enumerate Callback (mit enumerate_type connected) verschickt wird und es der Brick noch seine Konfiguration hat. Dies tritt z.b. bei einer 2. Verbindung über die WIFI Extension auf. Es kann allerdings nicht passieren, dass der Enumerate Callback nicht gesendet wird obwohl das Programm hätte informiert werden müssen.

Mit dem neuen Protokoll wird das Erstellen der Socketverbindung etwas anders. Daraus ergibt sich, dass die IPConnection dann connect und disconnect Funktionen bekommt, das Autoreconnect einstellbar wird und dem Benutzer über connected und disconnected Callbacks der Zustand der Verbindung mitgeteilt wird. http://www.tinkerforge.com/doc/Protocol_20.html#connection-handling

Du brauchst den QNH für deinen Ort und für heute, da sich der Luftdruck über die Zeit ändert und auch von Ort zu Ort verschieden ist (wie im von AuronX verlinkten Thread beschrieben). Der "Reference Air Pressure" muss in mbar bzw. hPa angegeben werden. Welchen QNH hast du den eingetragen, welchen Luftdruck und welche Chip-Temperatur zeigt denn das Barometer bei dir überhaupt an?

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.

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

1.2.0 ist ein Typo, hab's im ersten Post korrigiert.

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.

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.

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

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

In der Dokumentation und in der nächsten brickv Version wird darauf hingewiesen wie es sich mit dem Power Mode verhält.

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.