photron

Kann ich hier nicht reproduzieren. Ein brick Neustart kann/sollte sich nicht auf die Hardware auswirken, da diese das gar nicht mitbekommen kann. Bist du sicher, dass du da nicht noch irgendwas im Hintergrund laufen hast, dass durch einen brickd Neustart (den es mittels Disconnected/Connected Callback mitbekommt) an der IO-16 herumstellt?

Hört sich nach einem Wackelkontakt in der Mini-USB Buchse des Bricks an, bzw. der Lötkontakte der Buchse zur Platine hin. Kannst du mal versuchen den Mini-USB Stecker etwas nach oben/unten/links/rechts auf Spannung zu setzen und zu halten, um zu sehen ob dann eine Verbindung zustande kommt?

Hast du mal ein anderes USB Kabel getestet? Es sieht mit so aus als wäre die USB Kommunikation unterbrochen bzw. gestört. Du kannst auch mal den USB Hub weglassen, wenn du den am PC noch dazwischen hast und auch mal einen anderen USB Port am PC testen.

Das ist komisch. Versuch mal bitte den Master Brick zu zu flashen: http://www.tinkerforge.com/de/doc/Software/Brickv.html#brick-firmware-flashing

Okay, dann mal zu den grundsätzlicheren Dingen Wenn du den Master Brick an USB anschließt leuchtet dann die blauen LEDs auf? Falls nicht, tun sie es wenn er Master Brick alleine ist, also nicht im Stack mit anderen Bricks und ohne Bricklets? Wenn die LEDs leuchten, dann sollte der Master Brick funktionieren. Was passiert wenn du den Master Brick an USB anschließt? Taucht de im Geräte Manager als Master Brick bzw. Tinkerforge Brick auf?

Broken_Mind, wenn du den Brick also am PC anschließt wird er erkannt und alles funktioniert wie es soll. Am Raspberry Pi war das auch mal so, wenn du dort aber jetzt den Brick per USB anschließt dann tauch er nicht im brickv auf? Dass heißt also, dass das Problem mit dem Raspberry Pi zusammenhängt, weil der Brick auch weiterhin am PC funktioniert aber nicht mehr am Raspberry Pi. brickd läuft aber noch auf dem Raspberry Pi und brickv kann auch einer Verbindung herstellen? Was sagt lsusb auf dem Raspberry Pi? Bricks sollten dort als MCS oder GrauTec Geräte mit der ID 16d0:063d aufgeführt werden. Hast du vielleicht einfach ein Stromversorgungsproblem am Raspberry Pi, dessen USB Stromversorgung nicht die beste ist? Schließt du nur einen Brick, oder einen Stack von mehreren Bricks an? Kannst du mal mit einem einzelnen Brick testen? Oder einen aktiven USB Hub zwischen schalten, falls einer zur Hand ist? Oder eine Step-Down Power Supply verwenden, falls einer zur Hand ist?

Da hatte sich wirklich ein Fehler in get_port_configuration in der IO-16 Firmware eingeschlichen. Das setzen der Portkonfiguration hat funktioniert, aber in der Abfrage im Getter wurde die Direktion Mask einfach nicht gesetzt. Das ist jetzt in Version 2.0.5 korrigiert. Danke für den Hinweis.

Plugins: IO-16 Bricklet 2.0.5 Fix direction_mask return of get_port_configuration Use correct internal register in set_selected_values Download: IO-16 Bricklet

Plugins: IO-16 Bricklet 2.0.5 Rückgabe der direction_mask von get_port_configuration korrigiert Interne Registerverwendung in set_selected_values korrigiert Download: IO-16 Bricklet

Okay, wir haben das hier mal nachgebaut und können dein Problem so nicht nachstellen. Was aber auffällt ist, dass du eine ungewöhnliche Weise verwendest um das PWM Signal einzustellen. Da scheint noch ein Problem im Servo Brick zu sein, dass im normalen Betrieb mit Servos aber nicht auftritt. Bei Änderung der Period werden nicht alle abhängigen Werte richtig neu berechnet. Das macht im Betrieb mit Servos wie gesagt kein Problem, da die Period hier fest ist. Du verwendest sie aber als den aktiven Stellwert. Ich schlage daher folgende alternative Vorgehensweise vor, die mehr der normalen Arbeitsweise des Servo Bricks entspricht: Pulse Width: 0 bis 20000 Degree: 0 bis 100 Velocitiy und Acceleration: 65535 Period: 20000 Jetzt kannst du über die Position zwischen 0 und 100 den High-Anteil des PWM Signals einstellen.

Okay, wenn du also den Servo Brick über brickv einstellst, dann leuchten die LEDs so wie sie sollen. Wenn du aber die gleichen Einstellungen über dein PHP Programm machst dann funktioniert es nicht. Ich gebe dir recht, dein PHP Programm setzt alles so wie es auch in deinem brickv Screenshot eingestellt ist. Das sollte also funktionieren. Du sagst, manchmal werden auch Einstellungen aus brickv nicht übernommen. Wie ist den die Verbindung zwischen deinem Programm und dem Servo Brick. Ist der einfach per USB angeschlossen? Vielleicht gehen da Aufrufe verloren, weil die Verbindung instabil ist. Aktivier mal ResponseExpected für alle Funktionen, dann sendet der Brick für alle Funktionsaufrufe auch eine Antwort und die PHP Bindings können feststellen, ob diese auch beim Brick angekommen sind. Etwa hier: $this->tinker_serv = new Tinkerforge\BrickServo(tfUID_SERVO, $this->tinker_conn); $this->tinker_serv->setResponseExpectedAll(True); Wenn dann ein Aufruf verloren geht, wird dir das per Exception mitgeteilt.

Dein Programm sieht gut aus. Was mir aber auffällt, ist dass für setEdgeCountConfig() nicht dokumentiert ist, dass dies den Zähler zurücksetzt. Dies ist aber nicht dein Problem, da du ja setEdgeCountConfig() nur aufruft wenn die Konfiguration nicht so ist wie sie sein sollte. Daher sollte setEdgeCountConfig() nur einmal aufgerufen werden. Bedingt durch die Art und Weise wie unser System arbeitet ist die maximale Abtastrate beschränkt. Ich habe hier gerade nochmal mit einem 250Hz Rechtecksignal mit 50% Dutycycle getestet und da verliert der Flankenzähler keine Flanke. Debounce war auf 1 gestellt. Du solltest also grundsätzlich deutlich mehr als 2200 Impulse/Minute (ca. 36Hz) erkennen können mit dem IDI4 Bricklet. Was aber ein Problem sein könnte ist die Länge des High-Pegels des Hallsensors im Windmesser. Wenn dieser zu kurz ist, dann kann das Bricklet ihn im Zweifelsfall nicht mehr erkennen. Wenn dein Windmesser jetzt am Rad nur an einer Stelle einen Magneten hat dann kann dies durchaus dein Problem hier sein. Um diese Problem zu beheben, falls es wirklich das Problem ist, dann müsstest du die Länge der High-Pegels verlängern. Eine Möglichkeit wäre mehr Magneten anzubringen, falls das der Windmesser zulässt. Das Ziel ist dann das Verhältnis von Magnet-Über-Sensor zu Kein-Magnet-Über-Sensor pro Umdrehung mehr in Richtung 50:50 zu verschieben und so die Länge des High-Pegels pro Umdrehung zu verlängern.

Dass heißt, dein PHP Programm tut nicht exakt das was brickv tut. Du musst also nur herausbekommen was der Unterschied zwischen den beiden ist. Dazu könntest du folgendes tun: Den Servo Brick in brickv so einstellen, dass es funktioniert und dann die komplette Konfiguration einmal in PHP auslesen und mit dem vergleichen was dein Programm einstellt. Irgendwo muss da ja ein Unterschied sein. Nachtrag: Hast du mal kontrolliert, dass du die richtige UID für den Servo Brick verwendest?

"Einfach die RGB-Werte runterzählen" ist im Prinzip schon das Richtige. Du kannst dir aber auch einfach ein Farbmodell nehmen, das Helligkeit kennt, wie HSL und HSV, dann dort deine Farbe definieren und nach RGB umrechnen. Die Frequenz, die du im brickv einstellen kannst, hat nichts mit der Farbdarstellung zu tun, sondern mit der Kommunikation zwischen Bricklet und LEDs.

Okay, dass heißt du setzt die LEDs einmal und das reicht schon um das Problem zu erzeugen? Ich hatte angenommen du setzt die LEDs immer wieder, um eine Animation zu erzeugen. Wenn das nicht der Fall ist dann sind alle meine Hinweise hinfällig. Soll das heißen: $ledStrip->setRGBValues(0, 2, $r, $g, $b); und dafür öfter für alle LED's? Nein, ich meinte das bezogen auf Animationen. Das typische Vorgehen hier ist auf den FrameRendered Callback zu reagieren und dann alle LEDs in einem Rutsch (Burst) neu zu setzen. Also ganz viele Setter-Aufrufe auf einmal ohne Pause dazwischen. Das könnte ein Problem sein, die Abhilfe wäre dann zwischen den Setter-Aufrufen kurze Pausen zu machen. Aber wenn du keine Animation machst und nicht ganz viele setRGBValues Aufrufe hintereinander weg machst, dann ist das nicht dein Problem. geht leider nicht, sonst fuktioniert das restliche "Netzwerk" nicht mehr richtig. Okay, wenn du nur 32 LEDs ab und zu setzt, dann ist der Datendurchsatz eher nicht dein Problem. Ist das vielleicht ein Problem mit exakt dem Stapel? Hast du exakt den Stapel mit LED Strip Bricklet dran mal per USB getestet? Oder mal einen anderen Bricklet Port an dem Stapel getestet? Oder ein anderes Bricklet Kabel?

Wie viele LEDs steuerst du denn mit welcher Framerate an? Möglicherweise reichen 500 kBaud nicht aus, um die Datenmenge schnell genug zu befördern, was dann zu Timeouts führt. Aufhängen sollte sich das System dadurch nicht, sobald du aufhörst mehr Daten zu schicken als dein System verkraften kann sollte es wieder normal reagieren. Was du testen kannst: - Baudrate für RS485 erhöhen - Weniger LEDs ansteuern - LEDs mit einer geringeren Framerate ansteuern - LED Daten nicht als Burst senden, sondern die set_rgb_values Aufrufe über die Länge des Frames verteilen

Ich hab das jetzt mal eingebaut. Hier eine Vorabversion zum Testen. tinkerforge_java_bindings_2_0_14_device_listener.zip

Bindings: Perl 2.0.1 Put all packages into Tinkerforge namespace Fix signature of get/set_response_expected(_all) functions to match the documentation Handle error code in response packages Add Error class to report an error code in addition to the error message Download: Perl

Bindings: Perl 2.0.1 Alle Packages sind jetzt im Tinkerforge Namespace Signatur der get/set_response_expected(_all) Funktionen entsprechend der Dokumetation korrigiert Error Code in Antwortpacketen werden behandelt Error Klasse hinzugefügt um neben der Fehlermeldung auch einen Fehlercode mitteilen zu können Download: Perl

Du kannst gettimeofday/localtime_r um die aktuelle lokale Zeit als struct zu erhalten: struct tm { int tm_sec; /* seconds */ int tm_min; /* minutes */ int tm_hour; /* hours */ int tm_mday; /* day of the month */ int tm_mon; /* month */ int tm_year; /* year */ int tm_wday; /* day of the week */ int tm_yday; /* day in the year */ int tm_isdst; /* daylight saving time */ }; Hier ein Beispiel: #include <stdio.h> #include <sys/time.h> #include <time.h> int main(void) { struct timeval tv; time_t ts; struct tm lt; tv.tv_sec = 0; tv.tv_usec = 0; gettimeofday(&tv, NULL); ts = tv.tv_sec; localtime_r(&ts, &lt); printf("year %d\n", 1900 + lt.tm_year); printf("month %02d\n", lt.tm_mon); printf("day %d\n", lt.tm_mday); printf("hour %d\n", lt.tm_hour); printf("min %02d\n", lt.tm_min); printf("sec %02d\n", lt.tm_sec); return 0; } Damit kannst du dann ein Programm bauen, das z.B. in einer Schleife jeweils eine Minute schläft per sleep(60) und sich dann wieder die aktuelle Zeit anschaut und wenn es 23:00 ist den Abschaltbefehl gibt.

Wie hast du denn das Bricklet jetzt konfiguriert? Kannst du mal den Code zeigen? An welchem Master Brick im Stack du das Bricklet anschließt spielt normalerweise keine Rolle. Welchen anderen Bricklets hast du denn noch angeschlossen?

Der Flankenzähler kann bis 4294967295 zählen.

Danke für den Hinweis, ist korrigiert.

Thanks for packaging our software and spreading the word. I did not actually test the packages, but here are some comments from just looking at the AUR webpages: The brickv package has a brickd dependency, but brickv can be used without brickd on the same system and even without brickd at all, if you're connected to a stack with a WIFI or Ethernet Extension. Maybe in archlinux packages can recommend other packages the way Debian packages can? brickd doesn't use libusb-0.1 as provided by the libusb-compat package, but it uses libusb-1.0 as provided by libusbx package. Because libusb-compat itself depends on libusb-1.0 brickd ends up with the correct dependency. You could just cut libusb-compat from the dependency chain and depend on libusb-1.0 directly. The Perl bindings you packaged from CPAN are not the official ones. They were created by a user, are incomplete and outdated by now. The official ones can be found here: http://www.tinkerforge.com/en/doc/Software/API_Bindings_Perl.html They are not on CPAN yet, but will be soon.

reto.koenig danke für die detaillierte Darstellung des Nutzens eines DeviceListeners. Es ist kein Problem eine DeviceListener Interface als Basis aller Device Listener einzubauen. Ich frage mich an der Stelle, ob man nicht einen Schritt weiter geht und einen TinkerforgeListener neben eines DeviceListeners einbaut, der dann als Basis für alle Listener dient, also auch der der IPConnected: Connected, Disconnected und Enumerate. Also so: interface TinkerforgeListener {} // Basis aller Listener interface EnumerateListener extends TinkerforgeListener {} interface DeviceListener extends TinkerforgeListener {} // Basis aller Device Listener interface StateChangedListener extends DeviceListener {} Was haltet ihr davon?