photron

Okay, laut dem brickd.log sieht brickd keine Bricks, warum ist nicht klar. brickd verwendet libusb für die USB Kommunikation. Starte den Service nochmal mit folgenden Optionen: --debug --libusb-debug --log-to-file Dann werden auch noch Debug Informationen von libusb ausgegeben, das könnte weiterhelfen.

Welche Windows Version hast du in der VM laufen? Unter Windows 8 wird ein Brick mit seinem richtigen Namen angezeigt, ein Master Brick taucht also als "Master Brick" auf. Unter früheren Windows Versionen tauchen alle Brick als "Tinkerforge Brick" auf. Ist das der Fall in der VM? Wenn nicht ist der Treiber für den Brick noch nicht richtig geladen. Hast du Brick Daemon in der VM installiert? Wie genau funktioniert denn ein Connect nicht? Wenn du auf Connect klickst, ändert sich der Knopf zu Disconnect, es tauchen aber keine Brick auf, oder kommt eine Fehlermeldung wenn du auf Connect klickst?

Wir empfehlen typischerweise Python, wenn es um's Programmierenlernen geht, unabhängig vom Alter der Zielgruppe Python hat als Scriptsprache z.B. den Vorteil, dass man sich nicht noch zusätzlich mit einem externen Compiler und möglicherweise einem Build-System befassen muss. Ein anderer Vorteil von Python ist die einfach Syntax im Vergleich zu vielen anderen Programmiersprachen.

Für Android entwickeln heißt Java programmieren. Da kommst du mit Visual Studio nicht weit, das stimmt. Wenn du dich auf Android fokussieren willst, dann ist sicherlich Android Studio das Richtige. Eine Java IDE die direkt auf Android zugeschnitten ist, ist allerdings noch Beta. Vorher war Eclipse die IDE der Wahl für Android. Wenn es um generelle Java Entwicklung geht ist Eclipse sicherlich immer noch genau das Richtige. Für Eclipse gibt es verschiedene Erweiterungen, um es für verschiedene anderen Sprachen wie C/C++, Python, etc zu verwenden. Wenn du deinem Sohn das Programmieren beibringen willst, dann ist es vielleicht gar nicht das Richtige direkt mit einer großen, komplexen IDE anzufangen. Für den erfahrenen Entwickler ist eine IDE gut und hilfreich. Zuvor muss man aber erstmal lernen mit der IDE umzugehen, neben der eigentlichen Aufgabe Programmieren zu lernen. Vielleicht reicht für den Anfang ein simpler Texteditor und eine Kommandozeile, oder eine einfach Java IDE wie BlueJ, die sich direkt an Anfänger richtet. Persönlich verwende ich derzeit primär Geany (Texteditor mit Syntax Highlighting) und kompilieren und debugge auf der Kommandozeile. Ich habe aber auch schon verschiedenste IDEs für verschiedenste Zwecke verwendet, darunter JCreator, Eclipse JDT/CDT/ADT, Visual Studio (6 und neuer), Dev-C++, Qt Creator, KDevelop, Anjuta, Code::Blocks, etc. Alle haben ihre Vor- und Nachteile. Aktuell bin ich sozusagen mit IDEs durch und wieder bei Texteditor und Kommandozeile angekommen

Richtig, du kannst die USB Verbindung zum Brick durch eine Netzwerkverbindung mittels WIFI oder Ethernet Extension ersetzen. Ein Brick muss aber nicht an dem PC/VM per USB angeschlossen werden, auf dem du Brick Viewer verwenden willst. Du kannst den Brick an irgendeinen PC per USB anschließen. Auf diesem PC muss dann der Brick Daemon laufen und du kannst dich dann von überall im Netzwerk zu diesem PC per Brick Viewer verbinden un den Brick erreichen.

Der Brick sollte entweder im Bootloader sein (AT91 USB to Serial Converter) oder seine Firmware ausführen und als Brick auftauchen. Wenn er als unbekanntes Gerät auftritt oder der Geräte Manager ein Fehler angezeigt wird ist irgendwas nicht richtig. Hast du Bricklets angeschlossen? Wenn ja, funktioniert es ohne Bricklets? Versuch den Brick nochmal in Bootloader zu bringen. Es kommt in sehr seltenen Fällen vor, dass der Brick in einem komischen Zustand zwischen Bootloader und Firmware ist. Dann hilft es normalerweise den Brick nochmal in den Bootloader zu bringen. Es könnte auch ein USB Kommunikationsproblem sein. Hast du mal ein anderes USB Kabel probiert? Da du schon an zwei PCs getestet hast, liegt es wahrscheinlich nicht an der USB Buchse des PCs. Schau dir mal Erase und Reset Knopf genauer an. Machen beide beim Drücken ein Klickgeräusch und bewegt sich der kleine schwarze Knopf nach dem Drücken von selbst wieder in seine Ausgangsposition zurück? Ansonsten bleiben noch die üblichen Verdächtigen: Krumme Pins in den Bricklet Steckern.

Ich musst gerade erstmal ergooglen warum du mit Hyper-V RDP für's durchreichen von USB Geräten an eine VM brauchst: Hyper-V selbst kann das nicht, im Gegensatz zu anderen Hypervisorn. Bricks verwenden keine der vordefinierten USB Klassen (Mass Storage, Keyboard, Mouse, etc), sondern eine Vendor Specific Class. Wenn RDP nur vordefinierten USB Klassen durchreichen kann, dann klappt das mit Bricks nicht. Taucht denn der Brick im Geräte Manager im Windows in der VM auf, wenn du ihn durchgereicht hast? Bist du auf Hyper-V angewiesen? Ansonsten verwenden wir hier Virtual Box, da funktioniert das Durchreichen von Bricks einwandfrei. Mit VMware Workstation habe ich das noch nicht getestet, sollte aber höchstwahrscheinlich auch funktionieren.

jan, der RED Brick kann Master des Stacks sein. Du kannst also Stepper Bricks direkt auf dem RED Brick stecken und verwenden, ohne Master Brick dazwischen.

Der RED Brick ist an sich ein kleiner Linux Rechner. Du wirst auf ihm alle Programmiersprachen verwenden können die du unter Linux verwenden kannst. Zum Beispiel C, C++, C#, Delphi, Java, JavaScript, Perl, PHP, Python, Ruby, VB.NET, etc.

Ja, das ist eine gute Möglichkeit das zu tun. Dein Script wird alle 5 Minuten durch cron gestartet. Bei jedem Start schaut dein Script in deiner Datenbank nach ob es gerade Zeit ist etwas an oder aus zu schalten. Falls das der Fall ist schaltet das Script nach Vorgabe aus der Datenbank. Oder falls gerade nichts zu schalten ist tut dein Srcipt nichts und beendet sich wieder. Das ganze beginnt dann alle 5 Minuten von neuem. Worauf du dabei möglicherweise achten musst, ist der Zeitprüfung etwas Ungenauigkeit zu erlauben. Je nachdem wie exakt cron die Zeiten einhält sollte dein Script z.B. 10:14-10:16 noch als 10:15 interpretieren.

Richtig, du kannst da keinen request_tag_id Aufruf weglassen. Du hast da kein Problem, dein Programm funktioniert richtig. Das NFC/RFID Bricklet sendet dir von sich aus keinen StateChange Callback von sich aus, abgesehen vom Initialization nach Idle Übergang, alles andere danach ist eine Reaktion auf Funktionsaufrufe in deinem Programm. Du rufst request_tag_id/request_page auf. Darauf hin führt das Bricklet intern die angeforderte Aufgabe aus. Da die NFC/RFID Funkkommunikation etwas Zeit dauert, kann das nicht in einem Getter Aufruf passieren, das würde das ganze System blockieren. Die Funktionen starten also eine Aufgabe, die dann im Hintergrund auf dem Bricklet durchgeführt wird. Der Zustand der Durchführung der Aufgabe wird dir per StateChange Callback mitgeteilt: - State ist Idle - Du rufst request_tag_id - State ändert sich zu RequestTagID, StateChange Callback wird verschickt - Tag ID wird per Funk abgefragt - Entweder klappt die Abfrage oder nicht, der State ändert sich zu RequestTagIDReady oder RequestTagIDError und wir dir per Callback mitgeteilt - Jetzt kannst du per get_tag_id die letzte gelesene und im Bricklet zwischengespeicherte TagID abfragen Der selbe Ablauf passiert für request_page. StateChange Callback sind immer eine Folge eines Funktionsaufrufs. Der State ist nicht da, um auszusagen ob da in Tag da liegt oder nicht oder ob er sich ändert, sondern der State sagt aus in welchem Zustand eine Aufgabe ist, die du angestoßen hast.

Das ist kein Problem, sondern so arbeitet dein Programm einfach! Du fängst im __main__ Block mit nfc.request_tag_id(nfc.TAG_TYPE_TYPE2) an und löst damit den ersten Callback aus, mit State 2 (STATE_REQUEST_TAG_ID, ein Tag ID Anfrage ist im Gange). Darauf hin fragst du im else Zweig cb_state_changed erneut eine Tag ID an, was vom Bricklet ignoriert wird (denke ich, hab's nicht nachgesehen). Der nächste Callback kommt dann mit State 130 (STATE_REQUEST_TAG_ID_READY, eine Tag ID wurde gefunden) oder State 194 (STATE_REQUEST_TAG_ID_ERROR, keine Tag ID wurde gefunden). Woraufhin du den Inhalt liest und am Ende wieder request_tag_id aufrufst. Wenn kein Tag zu lesen ist, ist dein Programm in einer request_tag_id/Callback-STATE_REQUEST_TAG_ID_ERROR Schleife und wartet darauf, dass ein Tag auftaucht. Daher bekommst du ständig Callbacks, da dein Program ständig nach dem Vorhandensein eins Tags fragt.

get_rgb_values ist richtig, das muss du jetzt nur wie set_rgb_values rückwärts verwenden. Hier ein kurzes Beispiel (ungetestet): # the number of LEDs to get the color for number_of_leds = ... all_r = [] all_g = [] all_b = [] # list of indices [0, 16, 32, ...] that are smaller than number_of_leds indices = range(0, number_of_leds, 16) for index in indices: # number of LEDs remaining, but not more than 16 length = min(number_of_leds - index, 16) r, g, b = led_strip.get_rgb_values(index, length) all_r += r[:length] all_g += g[:length] all_b += b[:length] Wie set_rgb_values arbeitet auch get_rgb_values auf 16er Blöcken. Die indices Liste beinhaltet alle Startindizes der 16er Blöcke bis zur angegebenen LED Anzahl (number_of_leds). In der Schleife werden die Blöcke dann abgefragt. Die Länge des Blocks wird jeweils berechnet. Für alle Blöcke außer dem Letzten ist die Länge 16, da für diese number_of_leds - index > 16 ist. Für den letzten Block kann die Länge kürzer sein. Zum Beispiel: number_of_leds ist 40, dann ist indices [0, 16, 32] und es wird get_rgb_values(0, 16), get_rgb_values(16, 16) und get_rgb_values(32, aufgerufen. 8 daher weil number_of_leds - index in diesem Fall 40 - 32 = 8 ist, also kleiner 16. Da get_rgb_values aber immer 3 Listen der Länge 16 zurück gibt müssen beim letzten Aufruf diese Listen gekürzt werden auf die wahre Länge, daher r[:length].

Komisch, sollte funktionieren. Die notwendigen Schritte sind: - Stack per USB anschließen - mit Brick Viewer zu localhost verbinden - auf dem Master Brick Tab einen Hostnamen eingeben - "Save WIFI Configuration" klicken Ich denke bis hier hast du das schon alles so gemacht. Jetzt muss der Stack neugestartet werden, da Änderungen an den Einstellungen der WIFI Extension erst nach einem Neustart wirksam werden. Zum Neustarten kannst du den Reset Knopf am Master Brick drücken, das ist der gewöhnliche Weg. Du kannst den Stack aber auch einmal komplett vom Strom trennen. Nach dem Neustarten sollte die grüne LED auf der WIFI Extension blinken, d.h. es wird versucht eine WLAN Verbindung herzustellen. Sobald die Verbindung hergestellt wurde leuchtet die grüne LED durchgängig. Jetzt solltest du dich zum Stack über WLAN verbinden können. Ob das mit dem eingestellten Hostname der WIFI Extension funktioniert hängt von deinem WLAN Router ab. Wenn du eine FritzBox hast funktioniert das, wenn du einen anderen WLAN Router hast kann es sein, dass das mit dem Hostnamen nicht klappt. In dem Fall muss du die IP Adresse der WIFI Extension direkt verwenden. Dass heißt, du musst den Stack per USB angeschlossen lassen bis die WLAN Verbindung steht und kannst dann im Brick Viewer auf dem Master Brick Tab über den Show Info Knopf die zugewiesenen IP Adresse ablesen. Diese kannst du dann statt des eingestellten Hostnames verwenden, um Brick Viewer mit dem Stack über WLAN zu verbinden. Die USB Verbindung kannst dann auch trennen. Normalerweise weisen WLAN Router einem Gerät immer die gleiche IP Adresse zu. du musst also nicht immer wieder die zugewiesene IP Adresse der WIFI Extension nach sehen, einmal sollte reichen.

Im Bild für die USB Verbindung sehe ich, dass du mohamed-PC als Host für die Verbindung des Brick Viewers angegeben hast. Ich nehme mal an, das ist der Name des PCs an dem Der Stack per USB angeschlossen ist. Im Bild für die WLAN Verbindung sehe ich, dass du als Hostname für die WIFI Extension auch mohamed-PC eingetragen hast. Das ist der Name unter dem der Stack über WLAN erreichbar sein soll. Das wird so nicht funktionieren, denke ich. Denn dieser Name ist schon an einen anderen PC im Netzwerk vergeben, der Hostname jedes Teilnehmers im Netzwerk muss eindeutig sein. Versuch also mal für die WIFI Extension einen Hostnamen zu vergeben der in deinem Netzwerk noch nicht existiert. Nachdem du die Konfiguration der WIFI Extension geändert und den Stack neu gestartet hast, solltest du den Stack über Brick Viewer mit seinem neuen Hostnamen erreichen können, sobald die grüne LED an der WIFI Extension dauerhaft leuchtet.

If you mean your previous prototype, I thought that was the point of the Semaphore and while loop? I can understand the problem with trying to execute the dispatchMeta reconnection stuff asynchronously. My first prototype for this was just a quick and dirty one. The CallbackThread did not wait for every dispatch directly, so the dispatch was asynchronous compared to the release version of the bindings. But it did wait at the end for outstanding dispatches with this crude semaphore and while loop pattern, to ensure that all callbacks are dispatched before the IPConnection gets disconnected and the CallbackThread ends. As I said: quick and dirty Why is this required though? Surely this is just a notification that a disconnect has happened. I guess it may limit some things you can do in the listener. It is not strictly required. It's only required if you want to maintain the way it currently works. Currently all bindings guarantee, that the disconnected callback gets dispatched after the socket was properly closed and before auto-reconnect (if enabled) starts. This means in the user-function bound to the disconnect callback you'll see the IPConnection in disconnected state. You can do a manual reconnect or enable/disable auto-reconnect their and it'll work as expected. Even though this is not a documented feature, someone might rely on it, so I try to avoid breaking this. The disconnected callback is the only callback that has to be dispatched synchronously if you want to maintain this behavior. Which means if you don't need this you can dispatch the disconnected callback asynchronously. All other callbacks can be dispatched asynchronously without problems, as they aren't involved in such special behaviors. I was hoping to get away from synchronous dispatch if possible, though can handle that if it's the only way. I had looked a bit at this approach before my first message, and couldn't see any obvious issues with asynchronous dispatch - the data passed into the call.. methods doesn't seem to be reused anywhere (eg. the data array is created each time as far as I can tell). You only need to dispatch all callbacks synchronous if you want to keep the behavior of the bindings completely unchanged. The only callback for which synchronous dispatch really matters is the disconnected callback. If you don't rely on the described behavior then you can dispatch all callback asynchronous. I don't see any problem with this approach, except from changes in the exact timing of things, which shouldn't be a problem normally. To sum this up: You can dispatch all callbacks asynchronously. There is no problem with this. Just keep in mind that this can change the exact circumstances under which the DisconnectedListeners are called. I changed the comment in the code to reflect this better: // to preserve the exact current behavior of the IPConnection all of the // following abstract methods have to operate synchronous. all listeners // have to be called before the methods return. this is especially important // for the DisconnectedListener, because the callback thread expects that // the user got informed about the disconnect event before it starts the // auto-reconnect logic. this is because the user shall get a chance to act // upon the disconnect event before the auto-reconnect logic starts. // // synchronous dispatch of the callback is only important if the current // behavior should be preserved exactly. all callbacks can also be dispatched // asynchronously. the only negative effect of asynchronous dispatch is // that the current order of operations around the disconnected callback // cannot be guaranteed anymore.

In the prototype the CallbackThread doesn't wait for the dispatch of the callbacks. In contrast to the released Java bindings that do synchronous dispatch. Asynchronous dispatch should be okay, but it could change the external behavior of the bindings, which may or may not be a problem. Currently I cannot think of any critical problem with asynchronous dispatch except one. The current reconnect logic in the CallbackThread requires the callDisconnectedListeners() method to dispatch the callback synchronously. But this could be fixed. With the prototype the reconnect logic runs in your event logic, instead of the CallbackThread. In a final version this would have to be changed. You might be right, this gets complex fast. So the much simpler approach could be to make the call*Listener() methods protected so you can override them as you suggested. Then I could also make the API contract for this methods says that you have to do synchronous dispatch. Maybe something like this naive approach (creating semaphores might be expensive): protected void callDeviceListener(final Device device, final byte functionID, final byte[] data) { final Semaphore semaphore = new Semaphore(0); EventQueue.invokeLater(new Runnable() { IPConnection.callDeviceListener(device, functionID, data); semaphore.release(); } semaphore.acquire(); } Then you have to do all the hard work. That's okay for me As a side note: The IPConnection class is split into IPConnectionBase and IPConnection because the Java bindings are used with some modifications as MATLAB/Octave bindings. This is why the call*Listener() methods are abstract in IPConnectionBase and the actual implementation is in different IPConnection classes. This allows the MATLAB/Octave bindings to implement them in the proper way for MATLAB/Octave. Attached is a second simpler prototype for your override suggestion. Edit: I cannot see any problem with this override approach. The order of execution in the bindings doesn't change. Only the callback dispatch might be slightly delayed because of the round trip through your event loop, but that should not be a problem at all. tinkerforge_java_bindings_2_1_2_b3f88827594183802a72f623c4dfcdeb7e3c33f7+2_simpler.zip

It's not that simple. The internals of the IPConnection have to work in certain ways. We cannot just replace the whole CallbackThread with a user controlled construct, because the CallbackThread does more than just dispatching callback, it's responsible for some internal book keeping. The CallbackThread has to stay. But we could add an "inofficial" CallbackDispatcher interface for the CallbackThread. This lets you inject code between the CallbackThread and the actual dispatch of the callback: ipcon.setCallbackDispatcher(new IPConnection.CallbackDispatcher() { public void callbackReceived(IPConnection.Callback callback) { callback.dispatch(); } }); The callbacks are still dispatched by the CallbackThread by default as before. But if you set a CallbackDispatcher then the CallbackThread will pass callback objects to it and it has to call their dispatch method to dispatch them. Here you can pass them to your Swing event queue and make the event loop call the dispatch function. Be aware that you need to ensure that all callbacks delivered to the dispatcher are dispatched at some point, otherwise you can block a disconnect call. Attached is a first prototype for this. tinkerforge_java_bindings_2_1_2_b3f88827594183802a72f623c4dfcdeb7e3c33f7+1.zip

We could probably do something similar to the manual callback dispatch in PHP: IPConnection::dispatchCallbacks() This could be done by adding the following methods to the IPConnection class: void setAutomaticCallbackDispatch(boolean enabled); boolean getAutomaticCallbackDispatch(); void dispatchCallbacks(int duration);

Wenn du Interesse daran hast Go Bindings zu erstellen, die wir dann nachher auch weiterverwenden können, dann solltest du dich an der Struktur aller bestehenden Bindings orientieren. Wenn die Struktur der API und die Struktur der Implementierung aller Bindings gleich (oder zumindest sehr ähnlich ist) dann sind sie einfacher zu verstehen und zu pflegen. Wenn du Fragen zu den Interna der Bindings und der Generatoren hast, dann immer nur aus damit

Wir planen dazu folgende Erweiterungen: Kamerasteuerung (auslösen/fokussieren) ist mittel Industrial Quad Relay vorgesehen. Unsere Kamera hier hat für den kabelgebundenen Auslöser einen 2,5mm Standard Stereoklinken-Anschluss bei dem man einfach nur 2 Kontakte kurzschließen muss zum auslösen/fokussieren. Was wird dann auch die dazugehörige Software können. Zum Beispiel X Schritte fahren, auslösen, Y Sekunden warten und dann wieder X Schritte fahren usw. Endschalter für automatische Kalibrierung der möglichen Fahrstrecke. Ohne Endschalter muss beim Start einmal manuell die möglichen Fahrstrecke kalibriert werden.

Definitiv nur auf einer Seite die Abschirmung auf Masse legen, nicht auf beiden Seite. Vorzugsweise an der Bricklet Seite die Abschirmung auf Masse legen.

Okay, dann scheint da wohl der I2C Port Expander auf dem Bricklet ein Problem zu haben. Melde dich mal mit deiner Bestellnummer bei info@tinkerforge.com

Du könntest ein altes geschirmtes Ethernet oder USB Kabel dafür opfern und damit dein bisheriges Kabel ersetzen.

Die 3V Angabe im Shop ist leider falsch, sorry. Wir verkaufen die Variante mit Status LED, für die die Mindest-Eingangsspannung bei 4V liegt. Ich habe die Angabe im Shop korrigiert. Daher solltest du die IO-16 im 5V Modus verwenden, um auf der sicheren Seite zu sein.