photron

Teste mal bitte, ob es einen Unterschied macht, wenn du den set_wifi_power_mode() Aufruf kurz vor der Problemstelle entfernst.

Während du im Brick Viewer die Tabs wechselst usw. bliebt das eigentliche Gewicht, das auf der Wägezelle lastet aber gleich? Der Graph im Brick Viewer wird nur aktualisiert, wenn der Tab auch sichtbar ist. Sprich, wenn du die Wägezelle mit 1kg belastet, den Load Cell Tab abwählst, das Gewicht änderst du dann den Load Cell Tab wieder auswählst, dann springt der Graph. Die Änderungen den Gewichts während der Tab nicht sichtbar war wurden nicht aufgezeichnet. Ich nehme an das hier tritt bei dir nicht auf, da das Gewicht auf der Wägezelle konstant bliebt, oder? Die Messung einer Wägezelle erfolgt analog. An zwei Anschlüssen der Wägezelle wird eine Spannung eingespeist und an den zwei anderen Anschlüssen wieder zurück gemessen. Die Wägezelle tritt dabei als veränderlicher "Spannungsteiler" auf. 5m ungeschirmtes Kabel geben eine prima Antenne ab. Dadurch können externe Störungen die Messung beeinflussen. Auch wird der Spannungsabfall über 5m Kabel die Messung verfälschen. Besteht die Möglichkeit, dass du den Aufbau mit einem deutlich kürzeren Kabel zwischen Bricklet und Wägezelle testet?

Du registrierst hier die cb_temperature Funktion für den Temperatur Callback: # Register temperature callback to function cb_temperature t.register_callback(t.CALLBACK_TEMPERATURE, cb_temperature) Die t.CALLBACK_TEMPERATURE Konstante identifiziert den Temperatur Callback, damit register_callback weiss worum es geht. Die Bindings rufen dann deine cb_temperature Funktion auf und übergeben die aktuelle Temperatur sobald das Bricklet eine Änderung der Temperatur meldet. Du kannst also deinen publish() Aufruf in die cb_temperature() Funktion verlegen.

Das Temperature Bricklet hat nicht geantwortet (Timeout). Hast du vielleicht das Temperature Bricklet getauscht und die entsprechende UID in deinem Programm nicht angepasst? Taucht das betroffene Temperature Bricklet noch im Brick Viewer auf? Hast sich vielleicht das Bricklet Kabel gelöst?

Du brauchst raw_input(), ansonsten funktionieren das Callback Examples nicht, wie du schon selbst gesehen hast. Python buffered Ausgaben zwischen, dadurch siehst du sie nicht direkt im stdout.log während das Programm läuft. Du kannst Python auf unbuffered stellen. Dazu muss du hier Python -u als Argument übergeben: http://www.tinkerforge.com/de/doc/Hardware/Bricks/RED_Brick_Program_Tab.html#python Um Temperatur Daten an einen Server zu senden kannst du das Callback Example nehmen, raw_input() und ipcon.disconnect() drin lassen und in der cb_temperature() Funktion den Code einfügen, der die Daten an den Server sendet. Dann das modifizierte Beispiel auf den RED Brick laden und laufen lassen.

In den Beispielen, die den Bindings beiliegen, ist vor dem ipcon.disconnect() Aufruf ein input() Aufruf, der das Skript an der Stelle warten lässt bis eine Taste gedrückt wurde. Dadurch können die Bindings im Hintergrund eingehende Humidity Callbacks empfangen und an deine cb_humidity weiterreichen. Dein Skript konfiguriert alles um Humidity Callbacks zu empfangen und beendet sich dann. Daher bekommst du keine Ausgabe. Du musst also den input() Aufruf wieder einbauen, oder etwas alternatives, dass den gleichen Zweck erfüllt, das Skript vom sich beenden abzuhalten.

Ich denke nicht, dass es an Spannungsschwankungen am USB Port liegt, denn das Load Cell Bricklet verwendet diese 5V nicht direkt, sondern lokal regulierte 3,3V. Außerdem sagst du ja selbst, dass ein aktiver USB Hub keine Abhilfe bringt. Wie machst du die Kontrollmessung, mit der du erkennst, dass sich das gemessene Gewicht ändert, wenn das Brick Viewer Fenster auf ist? Muss du in Brick Viewer den Tab des Load Cell Bricklets auswählen, oder reicht es auch schon wenn der Setup Tab angezeigt wird?

Hast du noch einen anderen Brick, um testen zu können ob das Problem am Master Brick oder an den Bricklets liegt? Wobei es schon sehr auf den Master Brick hindeutet, dass keines der drei Bricklets funktioniert. Ansonsten melde dich bitte mit deiner Bestellnummer und einem Verweis auf diesen Thread hier bei info@tinkerforge.com. Du bekommst dann einen neuen Master Brick.

Das ist komisch, dass das gleich drei Bricklets gleichzeitig betrifft. Sind vielleicht in irgendeinem der Bricklet Stecker an den Bricklets oder dem Master Brick Beinchen krum, wie auf diesem bild hier? http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz

Okay, der Master Brick alleine funktioniert also und taucht im Brick Viewer auf. Sobald ein Bricklet angeschlossen ist, dann taucht auch der Master Brick nicht mehr im Brick Viewer auf? Bis du schon mal diesen Punkt im FAQ durchgegangen? http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricklets-wird-im-brick-viewer-nicht-angezeigt

Ahhh! Okay, du kannst hier am Ende der Seite die paho-mqtt-1.1.tar.gz Datei herunterladen: https://pypi.python.org/pypi/paho-mqtt Diese muss du dann auf's RED Brick übertragen. Am einfachsten lädst du sie mit deinem Programm mit hoch. Dann auf dem RED Brick (im Brick Viewer RED Brick Console Tab) in das bin Verzeichnis deines Programms wechseln: cd programs/<id>/bin <id> ist der Identifier deines Programms der in Brick Viewer angezeigt wird. Dort die paho-mqtt-1.1.tar.gz Datei eintpacken tar -xvf paho-mqtt-1.1.tar.gz Ins entpackte Verzeichnis wechseln: cd paho-mqtt-1.1 und per setup.py installieren: sudo python setup.py install

Okay ich habe folgendes getestet: - frisches RED Brick 1.7er Image - über WLAN USB Stick eine Internetverbindung hergestellt - im Brick Viewer den Consolen Tab aufgerufen und verbunden, alles weitere passiert auf dem RED Brick - in python scheitert "import paho.mqtt.client" wie erwartet, da paho-mqtt noch nicht installiert ist - paho-mqtt mittels "sudo pip install paho-mqtt" installiert, ohne sudo lädt pip das Package zwar runter kann es dann aber wegen fehlender Rechte nicht installieren - jetzt funktioniert "import paho.mqtt.client" in python Sprich es funktioniert wie erwartet. Ich verstehe nicht, wie pip das bei dir ohne root Rechte installiert haben soll. Welchen Fehler bekommst du denn, wenn du "sudo pip install paho-mqtt" ausführst?

ImportError: No module named paho.mqtt.client und ImportError: No module named paho.mqtt.publish sind zwei verschiedene Fehler. Irgendwas stimmt da mit deiner paho-mqtt Installation nicht. Bist du sicher, dass du das richtig installiert hast? Ich habe das hier gerade mal getestet und es funktioniert bei mir. Hast du vielleicht pip install paho-mqtt ohne sudo ausgeführt?

Das ist komisch. Der import Fehler scheint nicht direkt in deinem Script zu sein. Was passiert, wenn du auf dem RED Brick Console Tab Python startet und dort einfach import paho.mqtt.client ausführst?

I tested with R2012a. I think I found the problem. There's a change about how callbacks are handled in R2014a, see http://undocumentedmatlab.com/blog/matlab-callbacks-for-java-events-in-r2014a According to that blog post you need to replace vc = BrickletVoltageCurrent(UID, ipcon); with vc = handle(BrickletVoltageCurrent(UID, ipcon), 'CallbackProperties'); to expose callbacks again. Could you test that?

Brick Viewer 2.3.2 Ignore errors during locale initialization Change modeless dialog handling to workaround problem on Mac OS X Downloads: Windows, Linux, Mac OS X

Brick Viewer 2.3.2 Fehler bei der Locale Initialisierung werden ignoriert Handhabung nicht-modaler Dialoge geändert, um Problem auf Mac OS X zu umgehen Downloads: Windows, Linux, Mac OS X

Wie hast du paho-mqtt installiert? Verwendet dein Script vielleicht Python 2, du hast paho-mqtt aber für Python 3 installier oder anders herum?

Dann würde ich das im Moment auf die Beta schieben. Ich denke es lohnt sich nicht, dass im Moment zu Debuggen woran das liegt, auch wenn das heißt, das dein Master Brick nicht direkt an USB funktioniert, sorry. Wenn das Problem weiter besteht, wenn diese OSX Version aus Beta raus ist, dann sollte wir darauf zurück kommen.

Sehr gut! Behebt sie auch dein Master Brick Problem?

Ja, das Problem schein alle nicht-modalen bzw. nicht-blockierenden Dialoge zu betreffen, außer Updates / Flashing. Ich denke ich habe das Problem umgangen. Teste mal bitte diese Version: http://download.tinkerforge.com/_stuff/brickv_macos_2_3_2_rc1.dmg

Teste mal bitte diese Version: http://download.tinkerforge.com/_stuff/brickv_macos_2_3_2_rc1.dmg Bezüglich des Master Bricks: - Das ist höchstwahrscheinlich kein Brick Viewer Problem. - Wenn du den Master Brick per USB anschließt, leuchten dann LEDs am Master Brick auf? - Hast du mal ein anderes USB Kabel probiert?

Okay, wird behoben. Kannst in der Zwischenzeit einen Blick auf diesen Thread mit einem anderen Mac Problem werfen: http://www.tinkerunity.org/forum/index.php/topic,3371.0.html Auch wenn du das gerade nicht mit 2.3.1 testen kannst wüsste ich gerne, ob das dort beschriebene Problem bei dir mit 2.3.0 oder auch älteren Brick Viewer Versionen auftritt.

Der Vergleich hinkt etwas Wir haben das Netzteil hier mit mehr als 8A Last im Dauertest laufen lassen. Das war im Rahmen des Blinkenlights Kits, also 200 RGB LED Pixel dauerhaft bei voller Helligkeit, macht 12A. Das Netzteil wird dabei schnell recht warm und schaltet sich dann von selbst ab. Es besteht also keine Gefahr, dass das Netzeil kaputt geht oder sonst was schlimmes passiert.

Ploby, erst mit Brick Viewer 2.3.1, oder auch schon mit 2.3.0?