photron

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.

Der dispatch Befehle wartet standardmäßig unendlich lange auf eingehende Callbacks. Die --duration Option kann genutzt werden um das zu ändern. Bei --duration 0 beenden sich der Befehle nach dem ersten behandelten Callback. Bei Werten > 0 wird der Wert als Zeit in Millisekunden interpretiert und für diese Zeit eingehende Callbacks behandelt. Weil --execute nicht in der gleichen Shell ausgeführt wird wie dein Script. Du kann also das Script so nicht aus --execute heraus beenden. Der interrupt callback hat zwei Paramter (interrupt-mask und value-mask) anhand derer du bestimmen kannst welche Pins den Interrupt ausgelöst haben und ob es sich um eine steigende oder fallende Flanke handelt.

Das Problem liegt daran, dass sich libusb an die Dokumentation von Apple hält, statt an Apples Beispielprogramme. Die Zeile um dies es geht ist diese hier: https://github.com/libusbx/libusbx/blob/master/libusb/os/darwin_usb.c#L626 Laut dem Kommentar zu dieser Zeile besagt die Apple Dokumentation, dass ein USB Gerät zuerst geöffnet werden muss, bevor man gewisse Informationen abfragen kann. Ein Beispielprogramm von Apple tut dies aber nicht. Die libusb Entwickler wollten aber auf der sicheren Seite sein und halten sich an die Dokumentation. Der Aufruf von USBDeviceOpenSeize ist aber genau der der deinen USB-Ethernet-Adapter aus dem Tritt bringt. Daher habe ich jetzt eingebaut, dass USBDeviceOpenSeize nur noch für nicht-Apple Geräte aufgerufen wird. Dadurch sollte diese Problem behoben sein und brickd weiterhin normal funktionieren.

Die Callbacks werden von einem Thread der IPConnection aufgerufen. Du darfst aber mit dem GUI nur direkt aus dem Haupt-Thread deines Programms heraus interagieren, sprich was du da tust ist nicht erlaubt. Dass das Programm zufällig in der KiUserCallbackDispatcher Funktion von Windows steht würde ich ehr als zufällig betrachten. Diese Funktion ist eine Funktion des Windows Kernels, sie hat nichts direkt mit den Delphi Bindings zu tun. Um das Problem zu lösen musst du die Interaktion mit dem GUI in den Haupt-Thread verschieben, dazu kannst du z.B. TThread.Synchronize verwenden.