photron

RED Brick Image 1.7 Kerneltreiber und Tools für mobile Internet Verbindung hinzugefügt Mehr Kerneltreiber für USB Geräte (Serielle Adatper, Kameras, WLAN Sticks, usw.) Kernel Header für den Bau von Kernelmodulen auf dem RED Brick Octave auf Version 3.6 zurückgestuft, damit Callbacks wieder funktionieren openHAB auf Version 1.7 aktualisiert Offizielles Mono 4 APT Repository hinzugefügt Brick Viewer auf Version 2.2.6 aktualisiert Alle Bindings aktualisiert: C/C++ 2.1.7, C# 2.1.6, Delphi/Lazarus 2.1.6, Java 2.1.5, JavaScript 2.0.5, LabVIEW 2.1.5, Mathematica 2.1.5, MATLAB/Octave 2.0.5, Perl 2.1.5, PHP 2.1.5, Python 2.1.5, Ruby 2.1.5, Shell 2.1.5, VB.NET 2.1.5 Download: RED Brick Image

Brick Viewer 2.2.6 Add mobile Internet configuration tab to RED Brick plugin Add hex-view to RS232 Bricklet plugin Avoid warnings when reading non-existing config file on Mac OS X Ensure programs directory exists on RED Brick before importing a program Add position column to main device tree Add support for Ambient Light Bricklet 2.0 to RED Brick server monitoring Make RED Brick filesystem resize process more robust Add option to build Lazarus projects on RED Brick Add exit button for RED Brick programs Add status column to RED Brick program list Add calibration dialog to Industrial Dual Analog In Bricklet plugin Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.2.6 Mobile Internet Konfigurations-Tab zum RED Brick Plugin hinzugefügt Hex-Ansicht zum RS232 Bricklet Plugin hinzugefügt Warnings beim Lesen nicht vorhandener Config Dateien auf Mac OS X werden vermieden Es wird sichergestellt, dass das Programs Verzeichnis auf dem RED Brick existiert, bevor ein Programm importiert wird Positions-Spalte zur Devices Liste hinzugefügt Support für Ambient Light Bricklet 2.0 zum RED Brick Server Monitoring hinzugefügt RED Brick Dateisystem-Vergrößerung wird robuster durchgeführt Lazarus Projekte können auf dem RED Brick kompiliert werden Exit Knopf für RED Brick Programme hinzugefügt Status-Spalte zur RED Brick Programmliste hinzugefügt Kalibrierungs-Dialog zum Industrial Dual Analog In Bricklet Plugin hinzugefügt Downloads: Windows, Linux, Mac OS X

Abmessung (B x T x H): 49 x 45 x 36mm Verkaufsstart: nächste Woche

Sehr komisch. Nur um das nochmal klarzustellen: - Du hast einen Master Brick per USB am PC, daran nur das LCD 20x4 Bricklet. - Nach dem Anstecken an USB startets du das Button Pressed Beispiel. - Dann funktionieren die Buttons erst und dann funktionieren sie nicht mehr. Wenn du die Buttons drückst kommen vom Beispiel keine Ausgaben mehr. - Wenn du den Master Brick resettest oder USB ab-/ansteckst geht es kurz wieder. Kommt das so hin? Dass betrifft alle vier Buttons? Welche Hardware und Firmware Versionen haben Master Brick und und LCD 20x4 Bricklet? Hast du mal versucht die Firmware des Bricks und des Bricklets neu zu flashen?

Dein Vorgehen sollte da keinen Effekt drauf haben. Die Button Callbacks sind nicht konfigurierbar und vor allem nicht abstellbar. Dass heißt, so lange du in deinem Programm den Callback registriert hast sollte das auch funktionieren. Hier hat jemand den gleichen Effekt, dass die Button Callbacks nicht mehr kommen, das LCD an sich aber weiter funktioniert: http://www.tinkerunity.org/forum/index.php/topic,3228.0.html

Passiert das nur im Brick Viewer oder tritt das z.B. auch in diesem Beispiel auf? http://www.tinkerforge.com/de/doc/Software/Bricklets/LCD20x4_Bricklet_Python.html#button-callback

Bindings: C/C++ 2.1.7, C# 2.1.6, Delphi/Lazarus 2.1.6, Java 2.1.5, JavaScript 2.0.5, LabVIEW 2.1.5, Mathematica 2.1.5, MATLAB/Octave 2.0.5, Perl 2.1.5, PHP 2.1.5, Python 2.1.5, Ruby 2.1.5, Shell 2.1.5, VB.NET 2.1.5 Add support for IMU Brick 2.0, Accelerometer, Ambient Light 2.0, Analog In 2.0, Analog Out 2.0, Dust Detector, Industrial Analog Out, Industrial Dual Analog In, Laser Range Finder, Load Cell and RS232 Bricklet [All] Add functions for all Bricks to turn status LEDs on and off [All] Add DEVICE_DISPLAY_NAME constant to all Device classes [All] Avoid possible connection state race condition on connect [All except PHP] Rename SHA1 to SHAone to avoid name collision with an FPC unit [Delphi/Lazarus] IPConnection implements java.io.Closeable interface [Java] Compile Tinkerforge.dll for .NET 2.0 and .NET 4.0 [LabVIEW] Add missing IP Connection examples to ZIP file [MATLAB/Octave] Fix packing of Unicode chars [Python, Shell] Add symbolic output for callbacks, escaped input and output of values and array ellipsis [shell] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET

Bindings: C/C++ 2.1.7, C# 2.1.6, Delphi/Lazarus 2.1.6, Java 2.1.5, JavaScript 2.0.5, LabVIEW 2.1.5, Mathematica 2.1.5, MATLAB/Octave 2.0.5, Perl 2.1.5, PHP 2.1.5, Python 2.1.5, Ruby 2.1.5, Shell 2.1.5, VB.NET 2.1.5 Support für IMU Brick 2.0, Accelerometer, Ambient Light 2.0, Analog In 2.0, Analog Out 2.0, Dust Detector, Industrial Analog Out, Industrial Dual Analog In, Laser Range Finder, Load Cell und RS232 Bricklet hinzugefügt [Alle] Funktionen zum ab- und anschalten der Brick-Status-LEDs hinzugefügt [Alle] DEVICE_DISPLAY_NAME Konstante zu allen Device Klassen hinzugefügt [Alle außer Shell] Mögliche Connection-State Race Condition beim Connect behoben [Alle außer PHP] SHA1 zu SHAone umbenannt, um eine Namenskollision mit einer FPC Unit zu vermeiden [Delphi/Lazarus] IPConnection implementiert java.io.Closeable Interface [Java] Tinkerforge.dll für .NET 2.0 und .NET 4.0 kompiliert [LabVIEW] Fehlende IP Connection Beispiele zur ZIP Datei hinzugefügt [MATLAB/Octave] Packen von Unicode Zeichen korrigiert [Python, Shell] Symbolische Ausgabe für Callbacks, escapte Ein- und Ausgabe von Werten und Array Abkürzungen hinzugefügt [shell] Download: C/C++, C#, Delphi/Lazarus, Java, JavaScript, LabVIEW, Mathematica, MATLAB/Octave, Perl, PHP, Python, Ruby, Shell, VB.NET

Mit Einstecken meinst du USB? Wenn das Problem auftritt, kannst du dann noch aufs LCD schreiben? Sind nur die Buttons betroffen, oder das ganze Bricklet?

jgmischke, ich würde erwarten, dass das kein Treiberproblem ist. Eigentlich sollten Tastatur und Maus die Standard USB Klassen dafür nutzen und daher vom Standardtreiber dafür behandlet werden. Bisher ist mir auch kein Fall bekannt, wo ein USB Gerät am RED Brick aus Stromversorgungsgründen nicht funktioniert hätte. Tauch denn ein neues USB Gerät in der lsusb Ausgabe auf dem RED Brick auf, wenn du es ansteckst? Funktionieren andere USB Geräte am USB Anschluss des RED Bricks, z.B. andere Bricks?

Du verwendest das schon richtig. Du musst natürlich sicherstellen, dass &t auch noch gültig ist, wenn der Callback aufgerufen wird. Wenn du das Registrieren des Callbacks in einer Funktion machst und dein t dort auf dem Stack liegt, dann ist dein t weg nachdem die Funktion durch ist.

Ja, das hört sich nach Hardwaredefekt an. Melde dich bitte mit der Bestellnummer der Lieferung bei info@tinkerforge.com und verweise auf den Thread hier.

Okay, andere Frage: Welche Firmware Version ist auf dem Master Brick? Kannst du mal diese drei Firmware Versionen testen: 2.2.2, 2.3.1, 2.3.2? Die kannst du hier herunterladen, im Brick Viewer "Custom" auswählen und die Firmware als Datei auswählen: http://download.tinkerforge.com/firmwares/bricks/master/

Zwischen der "Removing USB device" und "Added USB device" vergehen in deinem Fall 2,6 Sekunden. Das ist für einen normalen Reset eigentlich zu lang. Das brickd.log nach dem Timeout ist normal für diesen Fall. Dein Skript hat eine Anfrage gesendet, es hat aber innerhalb von 2,5 Sekunden niemand geantwortet. Dadurch ist in deinem Skript eine Timeout Exception aufgetreten, die du nicht behandelt hast. Das hat dann dein Skript beendet und die Verbindung zum Brick Daemon wurde geschlossen. Darauf hin beschwert sich Brick Daemon, dass für diese Verbindung noch offenen Anfragen da waren. Bezüglich Watchdog: Das ist ein interner Notfall-Mechanismus der Bricks, um sich aus Endlosschleifen durch einen Reset zu befreien. Das sollte nur passieren, wenn wir Bugs in der Firmware des Bricks haben. Das sollte niemals durch dein Skript ausgelöst werden können. Fragen: Wenn dieses Problem auftritt, dann hilft es nicht nur dein Python Skript neuzustarten, sondern du musst definitiv den Brick von USB ab- und wieder anstecken, bzw. den Reset Knopf am Brick drücken? Wie häufig tritt das Problem auf? Fällt es mit irgendwelchen Ereignissen zusammen, z.B. dem Einschalten eines anderen Gerätes? Was ist alles so am Master Brick angeschlossen?

Hast du das Makefile mit diesen absoluten Pfaden (/home/test/Projekt1/) von Hand geschrieben, oder kommt das aus einem Generator wie den Autotools oder CMake oder ähnlichem? Eigentlich wäre die bessere/richtigere Lösung relative Pfade im Makefile zu verwenden, bzw. das Makefile erst auf dem RED Brick mit absoluten Pfaden zu generieren.

Also, ich habe mir das jetzt noch mal im Detail angesehen und das Resize war etwas unglücklich realisiert. Es wurde am Endes de Bootprozesses durchgeführt. Zu diesem Zeitpunkt läuft der Brick Daemon auf dem RED Brick schon und ist daher im Brick Viewer zu sehen. Wobei das Resize aber noch laufen konnte. Was dann wahrscheinlich den Script Error hervorgerufen hat. In meinen Tests hat das Resize nie länger als 2 Minuten gedauert. Hast du vielleicht eine besonders langsame SD Karte? Oder Programme laufen, die den RED Brick auslasten? Ich habe das jetzt so geändert, dass das Resize vor dem Start des Brick Daemon auf dem RED Brick durchgeführt wird, so dass der RED Brick erst dann wieder im Brick Viewer auftaucht, wenn das Resize fertig ist. Dadurch kann sich das Resize nicht mehr mir Brick Viewer und anderen Programmen in die Quere kommen. Aus dem "This process may take a moment" ist jetzt folgendes geworden: "This process may take a moment. Depending on the size and speed of the Micro-SD card it can take 1 to 15 minutes until the RED Brick will show up in Brickv Viewer again."

Dann ist mir nicht klar warum das so nicht ging. Ist auch nicht bedeutend: chmod 0777 /home/tf/programs/<program-id>/bin funktioniert ja auch. Auch wenn jetzt dadurch jeder dahin schreiben kann, was aber nicht kritisch ist auf dem RED Brick.

Hm, da fehlt wohl ein Neustart nach dem "sudo usermod -a -G tf www-data" denke ich. Anyway, mit dem nächsten RED Brick Image wird das automatisch richtig funktionieren.

Deine PHP Datei wird vom Apache auf dem RED Brick ausgeliefert. Das hat erstmal nichts mit brickd oder WebSockets zu tun. Der Apache auf dem RED Brick ist nicht für HTTPS konfiguriert, daher liefert er die keine Seite über HTTPS.

Das ist alles genau richtig so. Ich nehme mal an du hast das Solarpanel an die Eingangsklemme angeschlossen und an der Ausgangsklemme ist nichts, oder das Multimeter angeschlossen. Die Spannung misst das Bricklet zwischen dem + und - Seite der Eingangsklemme. Daher siehst du die 5,4V die ein Panel erzeugt. Den Strom misst das Bricklet zwischen den beiden + Seiten der Eingangs- und Ausgangsklemme. Sprich es misst den Strom der über das Bricklet zwischen Eingang und Ausgang fließt. Wenn du also nichts am Ausgang angeschlossen hast fließt kein Strom über das Bricklet, daher 0A. Wenn du aber das Multimeter am Ausgang anschließt, dann fließt ein Strom über das Multimeter und den misst dann das Bricklet.

Dann hast du die alte Tinkerforge.dll nicht richtig ersetzt. Der Fehler 1386 besagt, dass LabVIEW die entsprechende .NET Klasse nicht finden kann. Das liegt in diesem Fall daran, dass die Tinkerforge.dll die im Moment den LabVIEW Bindings beiliegt für .NET 2.0 kompiliert ist. Damit kommen neuere Versionen von LabVIEW nicht parat und brauchen die Tinkerforge.dll für .NET 4.0. Genau eine solche Tinkerforge.dll habe ich dir gegeben. Mach mal folgendes: - Schließe LabVIEW komplett - Lösche die alte Tinkerforge.dll - Pack die neue Tinkerforge.dll und das Example für das NFC/RFID Bricklet in den gleichen Ordner - Öffne das Beispiel in LabVIEW Wenn das nicht hilft, dann auf den IPConnection Node doppelt klicken. Im "Select .NET Constructor" Dialog muss als Assembly "Tinkerforge(2.1.4.0)" ausgewählt sein. Wenn das nicht der Fall ist, oder einfach nur zur Sichereit, über den Browse Knopf die neue Tinkerforge.dll auswählen. Dann solle in der Objects-Liste darunter auch die IPConnection auftauchen (neben vielen anderen Dingen). Diese Auswählen und den Dialog mit Ok verlassen.

Nimm mal die angehängte Tinkerforge.dll statt die aus dem ZIP. Tinkerforge.dll

jgmischke, Brick Viewer ist nach 30 Sekunden fertig, weil er nur den Resize Befehl in rc.local einträgt und dann einen Neustart auslöst. Das eigentliche Resize passiert dann beim Neustart. Was du da siehst ist also erwartet. Ob jetzt aber 4 Minuten okay, oder schon zu lang sind bin ich mir nicht sicher.

Also eine parallele Schnittstelle mit 16Bit. Da sehe ich gerade keinen Grund warum, das nicht funktionieren sollte,