photron

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?

Die Dokumentation sagt jetzt explizit: Windows, Linux, Mac.

Während der Schlafphase läuft das Programm ja auch nicht, da will dann ja auch keiner mit dem Brick reden. Aber nach dem der Mac wieder aufgewacht ist ist die Kommunikation weiterhin unterbrochen. Ich hab mir das jetzt mal genauer angesehen und zumindest unter Linux und Mac ist es so, dass beim Suspend die USB Kommunikation beendet wird und beim Resume neu aufgebaut wird. brickd verwendet aber über den Suspend hinweg den gleichen libusb Handle für den Brick. Allerdings läuft dieser nach dem Resume ins Leere, weil durch den Neuaufbau der USB Kommunikation der Brick jetzt einen neuen/anderen Handle hat. Soweit ich das sehe kann brickd nicht erkennen, ob der Handle zum Brick ins Leere läuft oder nicht. Was brickd aber tun kann, ist auf die Ursache des Problems zu reagieren, den Suspend. Die angehängt brickd Version lauscht jetzt auf den Resume Event von Mac OS X, der besagt, dass der Rechner gerade aus einem Suspend aufgewacht ist. In diesem Fall schließt brickd alle linusb Handles und öffnet sie neu. LinTec, damit sollte dein Problem behoben sein. Kannst du das bestätigen? Für Linux habe ich auch eine Lösung in Arbeit und unter Windows muss ich noch testen ob das Problem dort überhaupt auftritt. brickd_macos_2_0_10_wakeup.dmg

Okay, eine LED wird kein Problem machen. Es gibt unter Linux und Mac das Problem, dass brickd nach einem Suspend nicht mehr mit den Bricks kommunizieren kann. Das kann durch einen Neustart von brickd oder eine Reset der Bricks behoben werden. Das Problem ist, dass brickd das nicht mitbekommt, wenn das passiert. Daher siehst du das auch nicht im Logfile. Ich denke ich weiß wie das Problem zu beheben ist, wenn brickd das Problem erkennen könnte. Daher meine Frage, ob dein Problem mit einem Suspend zusammenfällt. Wenn ja, dann ist es wahrscheinlich das oben genannt Problem und ich kann dir leider momentan keine wirkliche Lösung anbieten. Standardmäßig wird das Debug Loglevel nicht ausgegeben, da dies sehr detailliert Auskunft über die stattfindende Kommunikation gibt. Was dazu führen kann, dass brickd bei der Abarbeitung der Kommunikation durch die Logausgabe selbst merklich gebremst wird. Du kannst das Loglevel in /etc/brickd.conf einstellen und muss dann brickd neustarten, um die Änderungen zu übernehmen. Wobei dies wahrscheinlich keine weiteren Erkenntnisse bringen wird, da Fehler oder unerwartete Dinge auf Error und Warn Loglevel gemeldet werden und diese beiden standardmäßig ausgegeben werden.

Hast du am Quad Relay eine Last angeschlossen oder schaltet das einfach so vor sich hin? Ich nehme mal an das Problem ist jetzt schon mehrfach aufgetreten. Passiert das immer nach ca. 2 Stunden? Bzw. fällt das mit einem anderen Ereignis zusammen? Leg sich der Mac vielleicht genau dann schlafen wenn das passiert? Teste mal bitte ob es auch hilft brickd neuzustarten, statt USB ab und an zu stecken, wenn das Problem auftritt. Dazu in einem Terminal folgende Befehle ausführen: sudo launchctl stop com.tinkerforge.brickd sudo launchctl start com.tinkerforge.brickd

Sprachen die spezifisch für ein Betriebssystem oder eine Hardware Architektur kompiliert werden, müssen natürlich passend für das RED Brick kompiliert werden, bzw. können dann auf dem RED Brick kompiliert werden. Das wären z.B. C/C++ oder Delphi. Java und auch C# verwenden aber Bytecode der nicht spezifisch für ein Betriebssystem oder eine Architektur ist. Das der C# Compiler .dll und .exe Dateien erzeugt heißt nicht, dass diese spezifisch für Windows wären. Eine unter Windows erstelle C# .exe Datei läuft unverändert unter Linux mit Mono.

Vielleicht sind im Bricklet A am Master Brick zwei Pins krumm? Genau die die für Pin 2 und 3 des Bricklets zuständig sind?