photron

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,

Die neuen Bricklets sind ab heute bei unserem Bestücker in Produktion.

Wenn es im Brick Viewer geht, dann kann es kein elektrisches Problem sein. Es muss also im Beispiel stecken. Das Beispiel tätigt viele Einstellungen die nicht unbedingt nötig sind. Daher jetzt mal ein einfacheres Beispiel, das den Servo nur ein paar mal hin und her bewegen lässt. Bevor du dieses Beispiel testest solltest du einmal den Servo Brick resetten, damit alle Einstellungen zurückgesetzt werden auf Standard. #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "5VF7gc" # Change to your UID from tinkerforge.ip_connection import IPConnection from tinkerforge.brick_servo import Servo import time if __name__ == "__main__": ipcon = IPConnection() # Create IP connection servo = Servo(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected if servo.get_identity().device_identifier != Servo.DEVICE_IDENTIFIER: print("This is not a Servo Brick") else: servo.set_position(0, 9000) servo.enable(0) time.sleep(2) servo.set_position(0, -9000) time.sleep(2) servo.set_position(0, 9000) time.sleep(2) servo.set_position(0, -9000) input('Press key to exit\n') # Use input() in Python 3 ipcon.disconnect()

Die Zeilen stammen auf dem letzten Release der JavaScript Bindings. Das ist nicht die korrigierte Datei aus meinem Post. Teste mal die angehängte Version, bei der jetzt auch die Crypto Verwendung korrigiert ist. Tinkerforge_window_fixes.js

. (Punkt) steht für das aktuelle Verzeichnis, da sich die Angabe des Arbeitsverzeichnis (da wo es angegeben werden kann) immer relative auf das bin Verzeichnis des Programms bezieht. Der absolute Pfad des bin Verzeichnis leitet sich so her: /home/tf/programs/<program-id>/bin Jetzt zum eigentlichen Problem. Wenn du jetzt dein PHP Programm im Web Interface Modus über http://<red-brick>/programs/<program-id>/bin/index.php aufrufst führt Apache das PHP Skript aus. Dabei ist das aktuelle Verzeichnis das bin Verzeichnis des Programms. Das Problem dabei ist jetzt das Apache als User www-data läuft und damit auch das PHP Skript. Das bin Verzeichnis gehört aber dem User tf und www-data hat da keine Schreibrechte. Das werde ich für die nächste RED Brick Image Version per ACL beheben, so das www-data auch im bin Verzeichnis schreiben kann. Bis dahin kannst du den User www-data zur tf Group hinzufügen und dann der tf Group im bin Verzeichnis Schreibrechte geben. Dazu folgende Befehle auf dem RED Brick ausführen (<program-id> durch den Namen deines Programms ersetzen): sudo usermod -a -G tf www-data chmod 0775 /home/tf/programs/<program-id>/bin

Du möchtest also ein Bricklet Kabel trennen. Wenn das nicht schön werden muss kannst du dein eines Bricklet Kabel durch zwei kürzere ersetzen, die über einen Adapter verbunden werden. Also Bricklet <---Kabel1---> Adapter <---Kabel2---> Brick Der Adapter besteht aus zwei Breakout Bricklets die an ihren Stiftleisten 1:1 durchverbunden sind.

Jetzt mal ganz zurück. Wie kompliziert sind den deine Befehle? Hier ein ganz einfacher Ansatz: Du könntest ein IO-4 Bricklet an deine 4 übrigen Pins anschließen. Jeder Pin stellt dabei einen Befehl da. Ein Wechsel von Low auf High an einem Pin bedeutet dann, dass der Befehl für diesen Pin ausgeführt werden soll. Der Wechsel zurück von High auf Low hat keine Bedeutung.

In meiner Zeile 12810 steht ein langer Kommentar. Kannst du mal deine Zeile 12810 mit 5 Zeilen davor und danach posten, damit ich sehe was du meinst. Die letzte Verwendung von window bei mir ist in der getRandomUInt32() Funktion um an die Crypto Funktionen zu kommen. Das muss ich gleich noch ändern.

Habe es gerade so abgeändert im git. Die nächste Version wird diese Änderung beinhalten.

"global.window.Tinkerforge" ist redundant, es reicht auch "global.Tinkerforge" für das gleiche Ergebnis. Damit funktionieren die Bindings hier auch in einem einfachem WebWorker Test. Tinkerforge.js

Wenn es reicht dein Python Script neuzustarten, dann deutet das darauf hin, dass das Problem eher dort liegt. Ich hab mir dein Script angesehen, aber das ist auf den ersten Blick alles in Ordnung. Wenn das Problem auftritt, funktionieren die Buttons dann noch in Brick Viewer?

Da steht sich das perl Package mit einigen anderen Packages auf den Füssen. Ich denke, dass ist ein Bug im perl Package selbst. In dieser Situation verweigert apt-get die Arbeit, weil es erst diese Problem beseitigt haben will. Ich konnte das Problem reproduzieren und so auflösen: sudo dpkg --purge cpanminus sudo dpkg --purge liblocal-lib-perl sudo dpkg --purge libmodule-build-perl sudo dpkg --purge libjson-pp-perl sudo dpkg --purge perl-doc sudo apt-get -f install sudo apt-get upgrade Jetzt stehen sich systemd und systemd-shim im Weg: sudo dpkg --purge systemd-shim sudo apt-get -f install sudo apt-get install systemd-shim sudo apt-get upgrade