photron

Die dokumentierte und implementierte Signatur ist schon diese: void BrickletIO16::registerCallback(int $id, callable $callback, mixed $userData=NULL) Allerdings fehlte beim Aufruf des eigentlichen Callbacks die Übergabe des $userData Parameters, so dass bei deiner cb_io1 Funktion dann kein $userData Parameter ankommt. Das ist jetzt korrigiert. Angehängt die korrigierte Version zum Testen. tinkerforge_php_bindings_2_0_13_rc1.zip

Das Analog In Bricklet ist für Gleichspannung gemacht. Von deinem Bild her sieht das nach einer typischen Klingel mit 12V Wechselspannung aus. Bei der negativen Halbwelle verpolst du dann die Eingänge des Bricklet was erklären kann warum der Master Brick aus dem Takt kommt. Du kannst eine Diode zwischen Klingel und Bricklet setzen, so dass nur noch die positive Halbwelle durchkommt und das Bricklet nicht mehr verpolt wird.

Hört sich immer noch nach Wackelkontakt/Hardwaredefekt an Melde dich mit deiner Bestellnummer bei info@tinkerforge.com. Wir tauschen den Master Brick dann aus.

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.