photron

Das sind MakerBeam Scharniere.

Die GLIBC Versionsabhängigkeit ist zu hoch, weil ich diese brickd Version für ARMHF aus Versehen auf dem falschen Raspberry Pi mit zu neuem Debian Image gebaut hatte, sorry Testet mal bitte die angehängt Version. brickd-2.2.2_armhf.deb

First of all, you need to use Brick Daemon 2.2.2 for OS X El Capitan. Apple changed things in El Capitan that makes the brickd installer of earlier versions fail silently. This is fixed in brickd 2.2.2. Brick Daemon itself has no GUI. It runs in the background and translates between USB and TCP/IP. You can look at its log file at /var/log/brickd.log and you can check that is properly running as a launchd daemon with this command in a terminal: sudo launchctl list | grep brickd It should print one line with three values like this (the first number can be different): 1511 0 com.tinkerforge.brickd If it prints nothing, then brickd is not properly installed. If the first value is not a number but a dash (-) then brickd is not running. In that case you can start it with: sudo launchctl start com.tinkerforge.brickd The GUI program for testing Bricks and Bricklets is called Brick Viewer. After you installed Brick Viewer, start it and click its "Connect" button. Then Brick Viewer connects to Brick Daemon over TCP/IP and Brick Daemon translates this to USB for the Bricks and Bricklets connected to USB. Now you should see your Bricks and Bricklets in Brick Viewer.

Gimbal Lock ist ein Problem bei der Darstellung der Lage in Euler Winkeln. Das Problem beleibt auch dann bestehen, wenn du die Euler Winkel einzeln betrachtest. Intern rechnet die IMU nicht mit Euler Winkeln, daher haben die interen Berechnungen der IMU keinen Gimbal Lock. Die Darstellung der Lage als Quaternion ist vom Gimbal Lock der Euler Winkel nicht betroffen.

Hier 7 verschiedene Versionen zum Testen. Welche davon funktioniert und welche nicht? Tinkerforge_A.dll Tinkerforge_B.dll Tinkerforge_C.dll Tinkerforge_D.dll Tinkerforge_E.dll Tinkerforge_F.dll Tinkerforge_G.dll

Brick Daemon 2.2.2 Use uname to get RED Brick kernel release for loading Ethernet Extension kernel driver (hotfix-1: already released as part of RED Brick Image 1.6) Improve RED Brick SPI stack protocol error recovery (hotfix-2: already released as part of RED Brick Image 1.7) Add start menu link for logviewer.exe on Windows Adapt to file system protection changes in Mac OS X 10.11 Update libusb WDF co-installer for Windows Vista and 7 Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.2.2 RED Brick Kernel Release wird per uname ermittelt um den Ethernet Extension Kernel Treiber richtig zu laden (Hotfix-1: Bereits als Teil des RED Brick Image 1.6 veröffentlicht) RED Brick SPI Stack Protokoll Fehlerbehandlung verbessert (Hotfix-2: Bereits als Teil des RED Brick Image 1.7 veröffentlicht) Startmenü Verknüpfung zur logviewer.exe auf Windows hinzugefügt Installer an Änderungen des Dateisystem-Schutzes in Mac OS X 10.11 angepasst libusb WDF Co-Installer für Windows Vista und 7 aktualisiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Dieses neue Produkt ist eine Zusammenfassung mehrerer bestehender Produkte zu einem. Eine WIFI Bridge/Nugget ist eine Zusammenfassung von: - Master Brick - WIFI Extension in einer Platine, wobei der Master Brick Teil keine Stack-Funktion hat und nur einen Bricklet Port. Das Ziel des Ganzen ist es ein Bricklet möglichst einfach über WIFI erreichbar zu machen. Es gibt keinen funktionalen Unterschied zwischen WIFI Bridge und WIFI Nugget, dass sind nur zwei verschiedene mögliche Namen für das gleiche Ding.

Sagt die Meldung einfach nur, dass ein Fehler aufgetreten ist? Oder stehen da noch Details zum Fehler?

Die dynamische Lösung ist über den Enumerate Callback, so wie du sie da hast. Der Enumerate Callback gibt dir alle Informationen und erlaubt dir alle Bricks und Bricklets zu finden ohne vorher wissen zu müssen welche vorhanden sind und welche UIDs sie haben. Im Enumerate Callback findet GetIdentity keine Anwendung, da dir Enumerate schon alle Information gibt, die dir GetIdentity geben kann. GetIdentity ist für den Fall nützlich, dass du mit einem bestimmten Brick(let) arbeiten willst und dessen UID und Typ schon kennst. Dann kannst du ein entsprechendes Brick(let) Objekt erstellen, anhand der UID, und mit GetIdentity weitere Informationen über das Brick(let) erhalten. Zum Beispiel, seine Firmware Version oder die Position im Stack.

"MAC Address" auf dem Statusfenster ist die des Moduls. "BSSID" ist die MAC Adresse des verbundenen Access Points. Hast du dir mal den U.FL Stecker des Moduls angesehen? Steckst das Kabel da richtig drauf? Was du auch noch testen kannst ist die Extension als Access Point mit Static IP zu konfigurieren. Da sollte das Statusfenster dann nciht alles 0 sein und du kannst testen ob du dich damit vom Notebook aus damit verbinden kannst. Wenn das geht, dann funktioniert die Kommunikation zwischen Master Brick und WIFI Modul auf der Extension.

Siehe hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_MATLAB.html#function-vs-script-dateien Hier das Humidity Bricklet Callback Beispiel. Ich habe nur die letzte Zeile hinzugefügt und jetzt kann ich es per "octave octave_example_callback.m" von der Kommandozeile aus aufrufen und es funktioniert auch so auf dem RED Brick. function octave_example_callback() more off; HOST = "localhost"; PORT = 4223; UID = "qRH"; % Change to your UID ipcon = java_new("com.tinkerforge.IPConnection"); % Create IP connection h = java_new("com.tinkerforge.BrickletHumidity", UID, ipcon); % Create device object ipcon.connect(HOST, PORT); % Connect to brickd % Don't use device before ipcon is connected % Set Period for rh callback to 1s (1000ms) % Note: The callback is only called every second if the % humidity has changed since the last call! h.setHumidityCallbackPeriod(1000); % Register humidity callback to function cb_humidity h.addHumidityCallback(@cb_humidity); input("Press any key to exit...\n", "s"); ipcon.disconnect(); end % Callback function for humidity callback (parameter has unit %RH/10) function cb_humidity(e) fprintf("Relative Humidity: %g %%RH\n", e.humidity/10.0); end octave_example_callback(); % Diese Zeile ist neu

Wenn du die Extension erneut auf WIFI konfigurierst wird der Inhalt des EEPROMs auf Extension auf Default zurückgesetzt. Das hat nichts mit dem WIFI Modul auf der Extension an sich zu tun. Die Änderungen dadurch siehst du erst nach einem Reset des Master Bricks. Wenn nach einem Reset des Master Bricks deinen statischen IP Einstellungen immer noch da sind, dann hat das Neukonfigurieren nicht geklappt. Die MAC Adresse steht auf dem Statusfenster, wenn die Verbindung besteht. Warum Signalstärke und MAC Adresse beim Associating Zustand nicht angezeigt werden musst du borg fragen, das hat sicherlich interne Gründe. Du hast nicht zufälligerweise noch einen anderen Access Point zur Hand, zum testen? Oder kannst dein Smartphone oder Notebook testweise als Access Point konfigurieren?

Loetkolben, dass da auf dem Status Fenster als 0 ist wenn der Status "Associating" ist, ist normal und kein Zeichen für ein Problem. Deine WIFI Extension versucht sich mit dem eingestellten Access Point zu verbinden (Status Associating, grüne LED blinkt), schafft es aber nicht. Ich nehme mal an, andere Geräte können sich noch zum Access Point verbinden. Das Problem liegt also nicht auf der Access Point Seite? Es hat auch niemand etwas am Access Point verstellt? Hat der Access Point ein Log über WIFI Aktivität wo vielleicht was steht, dass er die WIFI Extension abgelehnt hat? Hast du mal versucht die WIFI Extension im Brick Viewer über den Configure Button oben rechts erneut auf WIFI zu konfigurieren (Factory Reset) und dann den Master Brick neu zustarten?

Stimmt, die Beispiel sind Function Files. Es funktioniert wenn ich unter der Function Definition die Funktion direkt aufrufe. Ich füge da gleich einen Hinweis in der Dokumentation für ein. Bezüglich Callbacks: Ich habe gerade nochmal das Humidity Callback Example getestet und das funktioniert. Wie sieht dein Callback Test aus?

Welches Kabel du verwenden solltest hängt von der Strecke zwischen den beiden RS485 Knoten ab. Für ein paar Meter tut es sicherlich jedes Kabel. Der Querschnitt ist nicht so bedeutend, da hier keine große Leistung übertragen wird. Für längere Strecken als ein paar Meter solltest du mindestens ein verdrilltes (twisted pair) Kabel verwenden. Telefonkabel ist häufig verdrillt, damit machst du sicherlich nichts falsch. Die nächste Stufe ist dann Ethernet-Kabel, das ist verdrillt und besser geschirmt. Da du in einem Telefon- und auch Ethernet-Kabel normalerweise mehrere verdrillte Paare hast solltest du für A und B ein Paar nehmen und GND über ein anderes Paar führen. Nachtrag: Ich habe der Dokumentation einen Empfehlung für Twisted Pair Kabel hinzugefügt.

Getter in den JavaScript Bindings sind async. Du musst getPort so aufrufen: // Get current value from port A as bitmask io.getPort('a', function (valueMask) { alert('Value Mask (Port A): ' + valueMask.toString(2)); }, function (error) { alert('Error: ' + error); } );

Das kommt wohl hin. In meiner 1-wöchigen Messreihe hatte ich am Mittag mit direkter Sonne um die 80000 - 90000 Lux.

Es gibt jetzt Plugin 2.0.2 für's Ambient Light Bricklet 2.0. Darin wird zwar nicht das aktuelle Problem dieses Threads gelöst, da es noch nicht ergründet wurde, aber es geht mehr oder weniger noch mal um das Problem, das ich schon in Version 2.0.1 angegangen habe (Sensor ist gesättigt) und um den Messbereich des Bricklets. Daher will ich das hier kurz erläutern. Wenn es viel heller als der eingestellt Messbereich ist oder die Integrationszeit zu hoch eingestellt ist für die aktuelle Helligkeit, dann kann der Sensor gesättigt sein. In diesem Fall hatte Plugin 2.0.0 versuch den Wert des gesättigten Sensors noch zu verwenden was zu falschen Ergebnissen führte. Das war das initiale Problem in diesem Thread. In Plugin 2.0.1 wurden dann im Fall eines gesättigten Sensors, dessen Messwerte ignoriert und der letzte noch gültige Werte wurde weiterhin vom Bricklet gemeldet. Das löste das Problem der falschen Werte, machte es dem Nutzer aber nicht einfach zu erkennen, dass der Sensor in Sättigung war und eigentlich die Konfiguration hätte geändert werden sollen. Stattdessen sah es so aus, als ob sich die Helligkeit nicht ändern würde. Zusätzlich war es schon seit Plugin 2.0.0 so, dass das Bricklet Werte außerhalb des eingestellten Bereichs zurückliefern konnte. Das ist bedingt dadurch, dass der Sensor ca. 150% über den eingestellten Bereich hinaus messen kann. Allerdings mit abnehmender Genauigkeit. Auch das hat hier im Thread Probleme gemacht. Wir haben uns darüber jetzt noch mal Gedanken gemacht. In Plugin 2.0.2 liefert das Bricklet jetzt 0,00 Lux zurück, wenn der Sensor in Sättigung ist. Wenn er nicht gesättigt ist, ist der minimale Wert jetzt 0,01 Lux. Dadurch kann der Nutzer jetzt direkt erkennen, ob der Sensor in Sättigung ist und entsprechend reagieren. Die Messwerte werden jetzt auf den eingestellten Messbereich +0,01 Lux beschränkt. Wenn der Messbereich also auf 0-8000 Lux eingestellt ist und das Bricklet 8000,01 Lux meldet, dann ist der wirkliche Messwert höher als 8000 Lux und der Messbereich sollte umgestellt werden. Da der 0-64000 Lux Bereich jetzt wirklich nur noch bis 64000 Lux ausgibt, gibt es einen zusätzlichen unbeschränkten (unlimited) Messbereich, der bis zum absoluten Maximum (ca. 100000 Lux) des Sensors messen kann, wobei in diesem Bereich über 64000 Lux allerdings die Genauigkeit abnimmt.

Plugin: Ambient Light Bricklet 2.0 2.0.2 Invalid values due to sensor saturation are reported as 0lux Clamp measured values to the configured illuminance range Add new unlimited illuminance range for unclamped measurements Download: Ambient Light Bricklet 2.0

Plugin: Ambient Light Bricklet 2.0 2.0.2 Ungültige Sensorwerte bedingt durch einen gesättigten Sensor werden als 0Lux gemeldet Sensorwerte werden auf den eingestellten Messbereich beschränkt Neuen unbeschränkten (unlimited) Messbereich hinzugefügt Download: Ambient Light Bricklet 2.0

Das rot-schwarze Kabel ist für die Stromversorgung des Schrittmotors. Es ist am schwarzen Anschluss des Stepper Bricks angeschlossen. Der Schrittmotor wird nicht über USB versorgt. Ups, das haben wir wohl im Blogpost unterschlagen. Parmaster, du meinst das schwarze Kabel mehr links im Bild, dass geht zur Kamera.

Die einfachste Erklärung ist, dass dennoch die UID nicht passt. Du hast aber auch die UID des Bricklets angeben? Die ist normalerweise 3 stellig. Du kannst testweise mal folgende Zeile nach der "$sd4x7 = new BrickletSegmentDisplay4x7(UID, $ipcon);" Zeile im Beispiel einfügen: $sd4x7->setResponseExpectedAll(true); Wenn dann ein Fehler auftritt hast du die falsche UID angegeben, denn dann hat niemand auf den setSegments() Aufruf geantwortet. Wenn kein Fehler auftritt, aber immer noch nichts angezeigt wird, dann hast du die UID des falschen Bricks oder Bricklets angegeben.

Die RED Brick API hat keine direkte Funktion dafür. Die API bietet grundlegende Funktionen wie Dateien auf dem RED Brick lesen/schreiben und Programme auszuführen. Darüber erledigt der Brick Viewer dann z.B. auch die Access Point Konfiguration. Das ist allerdings halbwegs kompliziert. Du kannst die den Code dafür im Brick Viewer u.a. hier ansehen: https://github.com/Tinkerforge/brickv/tree/master/src/brickv/plugin_system/plugins/red https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/red_tab_settings_ap.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_apply.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_get_interfaces.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_status.py

Signal 9 ist das Unix Signal SIGKILL. Wenn du im Brick Viewer den Kill Knopf für das Programm klickst, dann wird es mit SIGKILL umgebracht. Das wichtige an SIGKILL ist, dass sich das Programm nicht dagegen wehren kann. Wenn du den den Exit Knopf klickst wird das Programm mit SIGTERM (Signal 15) gebeten sich zu beenden. Wenn das Programm aber nicht will, kann es SIGTERM ignorieren. Sprich SIGKILL kann auftreten, wenn du den Kill Knopf klickst, was du wahrscheinlich nicht getan hast. Ansonsten kann SIGKILL auftreten, wenn du das Programm löscht während es noch läuft, oder der RED Brick API Daemon sich beendet wenn es noch läuft. Das wird aber alles hier nicht der Fall sein. Wie viel RAM braucht dein Programm? Es kann sein, dass dein Programm allen RAM des RED Bricks belegt. In dem Fall kommt der Linux OOM (Out-of-Memory) Killer ins Spiel, der so lange Programm (mit SIGKILL) umbringt bis wieder ausreichend RAM frei ist damit das System weiterlaufen kann.