photron

Erstmal vielen Dank für die ausgiebigen Tests und die Beschreibung der Ergebnisse EMV ist leider ein komplexes Thema Man könnte jetzt versucht sein Erkenntnisse aus deinen Tests abzuleiten: Zum Beispiel, könnte man behaupten, dass Master Brick 1 (mit den 3 Fenster Rollos) alleine funktioniert, weil die zu schaltende Motorlast kleiner ist als an Master Brick 2 (mit 4 Tür und Fenster Rollos). An Master Brick 2 ist die Last größer und damit die Störung größer, so dass sie hier über der Schwelle liegt die der Brick verträgt. Das muss aber nicht so sein. Vielleicht ist die Verkabelung an Master Brick 2 einfach anders und bildet eine bessere Antenne um Störungen einzufangen. Ähnlich liegt es mit dem Trennen des Stack zu zwei einzeln angeschlossenen Bricks. Dass das hilft liegt vielleicht daran, dass du dadurch Antennen verändert/verkleinert hast und jetzt weniger Störungen eingefangen werden. Bastians Hinweis mit dem Varistor zielte auf die induktive Last der Motoren ab, die möglicherweise im Relais beim Abschalten eine Funken erzeugen der dann den Master Brick stören kann. Hier kommt es auch wieder darauf an wie der Master Brick mit möglichen Antennen verbunden ist die Störung einfangen können. Das ist aber nur eine mögliche Störungsquelle. Wir haben hier schon einige Tests zu EMV im Bezug auf Relais gemacht, sind aber bisher nicht zu schlüssigen Ergebnissen gekommen. Wir sind da aber noch am Ball

Dass heißt, wenn du den Brick in die VM durchreichst meldet VMware jetzt keinen Fehler mehr. Taucht denn der Brick im Geräte Manager von Windows XP in der VM auf?

In diesem Programm erst zu fragen ob ein Brick(let) wirklich da ist, wobei dein Programm eigentlich davon ausgeht das es da ist, ist eigentlich nicht typisch Python. Typischer wäre es einfach die Getter aufzurufen und die Exception zu behandeln, die möglicherweise auftreten kann. Also z.B. so: try: voltage = master.get_stack_voltage()/1000.0 except Exception as e: print "get_stack_voltage() failed", str(e) Statt erst zu prüfen ob das Brick(let) vielleicht nicht da ist (wobei is_device_available() nicht in der Form existiert und nur der Verdeutlichung dient): if is_device_available(master): voltage = master.get_stack_voltage()/1000.0 Wenn davon auszugehen ist, dass meistens oder immer nicht alle Bricklets die dein Programm erwartet vorhanden sind, dann kann es sinnvoll sein zu erst per Enumerate zu erfragen was angeschlossen ist. Dann muss nur einmal kurz gewartet werden, statt bei jedem Aufruf einen möglichen Timeout abwarten zu müssen wenn ein erwartetes Brick(let) nicht vorhanden ist. Hier ein Beispiel, dass per Enumerate die Liste der bekannten UIDs aufbaut und aktuell hält (ungetestet): available_uids = set() def cb_enumerate(uid, connected_uid, position, hardware_version, firmware_version, device_identifier, enumeration_type): if enumeration_type == IPConnection.ENUMERATION_TYPE_DISCONNECTED: available_uids.remove(uid) else: available_uids.add(uid) if __name__ == "__main__": ipcon = IPConnection() ipcon.connect(HOST, PORT) ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, cb_enumerate) ipcon.enumerate() time.sleep(1) # wait a moment for enumerate callbacks print available_uids ipcon.disconnect() Du kannst jetzt prüfen ob deine erwartete UID in available_uids ist und dann entsprechend handeln. Dies kann aber nicht alle Fälle abdecken. Wenn dein Programm z.B. mittendrin die Verbindung zum Stack verliert werden die Funktionen der Brick(let) Objekte immer noch Exceptions werfen. Du kommst also um Fehlerbehandlung für ein robustes Programm nicht herum.

Das hört sich danach an als ob VMware ein Problem mit dem Durchreichen von USB Geräten (zumindest Bricks) hat. Wir verwenden hier VirtualBox und reichen auch ständig Bricks in die VM hinein, das funktioniert ohne Probleme. Kannst du denn andere USB Geräte in die VM durchreichen? Ist der Brick am Host an einem USB 3.0 Port (innen blau) angeschlossen? Vielleicht bereitet das VMware Probleme. Teste mal den Brick an einen USB 2.0 Port anzuschließen und dann in die VM durchzureichen. Dieser VMware Knowledge Base Eintrag hört sich relevant an.

Haben wir wirklich vergessen Ist jetzt korrigiert.

Plugins: Distance IR Bricklet 2.0.1 Don't send threshold callback twice erroneously anymore Downloads: Distance IR Bricklet

Plugins: Distance IR Bricklet 2.0.1 Threshold Callbacks werden nicht mehr fälschlicherweise zweimal nacheinander ausgelöst Downloads: Distance IR Bricklet

Brick Daemon 2.0.9 Use libusb hotplug support if available on Linux Update bundled libusb to 1.0.17 on Mac OS X, libusb hotplug replaces custom IOKit code Update bundled libusb to 1.0.17 on Windows, adds support for VIA VL805 USB 3.0 host controllers Add --libusb-debug option to enable libusb debug output Report too long lines in config file as errors instead of silently ignoring them Add IPv6 support with configurable dual-stack handling Don't interfere with Apple's USB Ethernet Adapter on Mac OS X Sign brickd.app and installer on Mac OS X to silence the Gate Keeper Linux packages build on older Debian/Ubuntu release to lower required glibc version Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Brick Daemon 2.0.9 libusb Hotplug Support wird auf Linux verwendet, wenn verfügbar Mitgelieferte libusb Version für Mac OS X auf 1.0.17 aktualisiert, libusb Hotplug ersetzt eigenen IOKit Code Mitgelieferte libusb Version für Windows auf 1.0.17 aktualisiert, Support für VIA VL805 USB 3.0 Host Controller hinzugefügt --libusb-debug Option hinzugefügt um libusb Debug Ausgabe zu aktivieren Zu lange Zeilen in der Config Datei werden als Fehler gemeldet anstatt sie zu ignorieren IPv6 Support mit einstellbarer Dual-Stack Behandlung hinzugefügt Apples USB Ethernet Adapter wird jetzt auf Mac OS X nicht mehr durch libusb gestört brickd.app und Installer sind jetzt auf Mac OS X signiert um den Gate Keeper ruhig zu stellen Linux Packages werden auf älterer Debian/Ubuntu Release gebaut um die benötigte glibc Version zu verringern Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Das geht mit der "io4.addInterruptListener(new BrickletIO4.InterruptListener() { ... }" Schreibweise nicht. Du kannst das so machen: BrickletIO4.InterruptListener listener = new BrickletIO4.InterruptListener() { public void interrupt(short interruptMask, short valueMask) { try { if (val == 14) { System.out.print("\nSchalter 1"); } if (val == 13) { System.out.print("\nSchalter 2"); } }catch(TinkerforgeException e) { } } }); io4.addInterruptListener(listener); ... io4.removeInterruptListener(listener);

KeyOz, lass mich das mal zusammenfassen. Dein Barometer Bricklet taucht noch im Brick Viewer zeigt aber als Werte 10 mbar, -40 °C und 0 m an. Dabei sind aber die SDA und SCL Leitung zum Barometer IC okay. Hast du dir schon die Bricklet Stecker am Bricklet und am Brick angesehen? Sind da vielleicht Pins krumm und machen einen Kurzschluss? Dann kannst du noch einmal die 3.3V Leitung messen (siehe Anhang). Wenn die auch okay ist kannst du auch noch das Plugin des Bricklets über den Brick Viewer einmal neu zu flashen.

Gut, gut, das hört sich vielversprechend an

Der Trick bei den PMs ist es im Antwort Dialog den Haken für "Kopie im Ausgang speichern" zu setzen Sorry, wegen 2.0.9 RC1, da hatte ich den Installer geändert und es nicht ordentlich genug getestet. Hier RC3, damit sollte jetzt alles in Ordnung sein. Diese Version ist jetzt auch signiert, so dass der Gate Keeper sie nicht mehr blockiert in der Standardeinstellung. http://download.tinkerforge.com/_stuff/brickd_macos_2_0_9_rc3.dmg Wenn die Version bei dir jetzt auch ordentlich funktioniert, wird das 2.0.9 final.

Wenn dein Barometer Bricklet noch im Brick Viewer auftaucht, dann sind SDA und SCL zwischen Stecker und EEPROM noch intakt. Wenn du 10mbar als Luftdruck angezeigt wird dann kann es an einer defekten I2C Leitung liegen, muss aber nicht unbedingt. Falls du ein Multi-Meter oder einen anderen Durchgangsprüfer zur Hand hast dann kannst du messen ob der I2C Bus noch intakt ist. Ich habe auf dem angehängten Bild aufgemalt wie die I2C Pins des Barometer ICs (weißer Chip) und des EEPROMs (schwarzer Chip) mit dem Stecker verbunden sein müssen, damit es funktioniert. Bei thunderbirds Barometern war jeweils die SDA Leitung zwischen Barometer IC und EEPROM unterbrochen. Wie verwendet du das Bricklet denn? Hast du das wie thunderbird auch draußen im Einsatz, wo es größeren Temperaturschwankungen ausgesetzt ist?

AFAIK you can power the Raspberry Pi via the 5V pins in its extension header. So this would allow this Step-Down Power Supply Shield to power the Raspberry Pi. This would allow to get rid of the cable from the Step-Down Power Supply to the Raspberry Pi. Do you suggest to have an USB hub on this Step-Down Power Supply Shield? One problem with this is that the extension header of the Raspberry Pi does not include USB pins. So you would need an USB cable between the shield and the Raspberry Pi and another USB cable between the shield and the Brick that is stacked on top of the shield, because there are no USB pins in the stack connectors. For just one Brick this doesn't make much sense. You could just connect it directly via USB and power it with this Step-Down Power Supply Shield. To inject 5V from the Step-Down Power Supply Shield into an USB host connector to power a Brick via USB, this would require an USB device connector on the Step-Down Power Supply Shield to connect it to the Raspberry Pi's USB port. If you want to run more than one Brick from this you need extra logic and will end up with a crossbreed of a Step-Down Power Supply and an active USB hub that happens to be powered by the Step-Down Power Supply.

Die SSID ist der Name des WLAN Netzes zu dem sich die WIFI Extension verbinden soll. Der Name unter dem die WIFI Extension dann zu erreichen ist ist der Hostname.

Rufst du auf dem gleichen io4 Objekt mehrfach addInterruptListener() auf? Dann fügst du beim jedem Durchlauf einen weiteren Listener hinzu und dann werden auch mehrere Listener ausgeführt. Wenn das nicht deine Absicht ist, dann solltest du addInterruptListener() nur einmal am Anfang aufrufen. removeInterruptListener(null) ergibt keinen Sinn. Wenn dann musst du dir eine Referenz zum Listner Objekt zwischen speichern: BrickletIO4.InterruptListener listener = new BrickletIO4.InterruptListener() { ... } io4.addInterruptListener(listener); ... io4.removeInterruptListener(listener);

Doch, hier http://www.tinkerforge.com/de/doc/Software/IPConnection_Shell.html#tinkerforge dispatch Wobei auf den Seiten der Bricks und Bricklets ein Link darauf fehlt. Ich werde gleich einen einfügen.

Dann musst du wahrscheinlich einfach nur wieder in den Sicherheitseinstellungen Software aus unbekannten Quellen zulassen, wie in der brickd Installationsanleitung beschrieben. Das wird aber auch in kürze ein Ende haben. Die nächste brickd Version wird höchstwahrschnlich signiert sein und dann hört Mac OS X auf zu meckern.

Die Parameter sind teils positionsabhängig: tinkerforge dispatch --duarion 0 io4-bricklet $io_uid interrupt ...

Funktioniert hier auf Mac OS X 10.8. Hast du vielleicht in der Zwischenzeit auf 10.9 aktualisiert, oder der Gate Keeper ist aus anderen Gründen wieder aktiviert?

Diese Aussage ist alt und nun falsch. Seit Protokoll 2.0 werden Packages mit unbekannter Function ID werden ignoriert, bzw wenn dass Response Expected Flag gesetzt ist, dann wir auch eine Response mit Error Code 2 (FUNCTION_NOT_SUPPORTED) zurück gesendet.

Du muss dafür die valueMask im Listener prüfen. Bei einer steigenden Flanke ist das Bit für den entsprechenden Pin in valueMask gesetzt, bei einer fallenden Flanke nicht.

Hier RC1 für brickd 2.0.9 zum testen: http://download.tinkerforge.com/_stuff/brickd_macos_2_0_9_rc1.dmg

Du kannst natürlich mehrere dispatch Aufrufe per --execute verketten. Ein dispatch Aufruf kann aber jeweils nur auf einen Callback warten. Die Shell Bindings sind in diesem Bezug nicht so mächtig wie die anderen Bindings.