photron

Verhält sich die angehängte Version besser? Admin-Edit: Veraltete brickd-Version entfernt.

Das ist komisch. Brick Daemon faked unter Windows Pipes mit zwei über localhost verbundenen Sockets. So eine Pipe ist auch die "USB Ready Pipe". Über diese Pipe wird der Event-Loop in brickd darüber informiert, dass USB Events vorliegen. Wenn das nicht funktioniert, dann "sieht" brickd die USB Geräte nicht. Warum es da zu einem Connection-Reset Fehler (WSAECONNRESET) kommt, ist mir nicht klar. An der zweiten Meldung ist komisch, dass da von COM die Rede ist. Ansonsten ließt sich das als ob brickd nicht das recht hätte zu sich selbst ein Socket Verbindung über localhost zu erstellen. Da es hilft den Dienst neuzustarten, könnte das ein Reihenfolgeproblem sein. Sprich brickd startet und erstellt die "USB Ready Pipe". Danach startet ein anderer Systemdienst der irgendwas mit localhost zutun hat. Das macht dann die Socket Verbindung über localhost in brickd kaputt. Ich kann das Problem hier auf unserem Windows 10 Labtop nicht nachstellen. Was hast du sonst so an Software installiert? Ich denke da zuerst an Virtualisierungssoftware, wie Hyper-V, VMware, Virtual Box etc. die was mit dem Netzwerk zu tun haben.

Es sieht aus als ob dir xbuild fehlt. Das kommt aus dem mono-xbuild Package, das Teil von mono-complete sein sollte. mono-complete sollte allerdings vom Build Environment Script installiert worden sein. Versuch mal das manual nachzuinstallieren: sudo apt-get install mono-xbuild

Firmware: WIFI Extension 2.0 2.0.2 Add missing ESP8266 SDK 2.0.0 configration binaries and adapt to ESP8266 configration API changes to fix boot and connection problems Download: WIFI Extension 2.0

Firmware: WIFI Extension 2.0 2.0.2 Fehlende ESP8266 SDK 2.0.0 Konfigurationsdateien hinzugefügt und Anpassungen an Änderungen in der ESP8266 Konfigurations API vorgenommen, um Start- und Verbindungsprobleme zu beheben Download: WIFI Extension 2.0

See this post in the German board: http://www.tinkerunity.org/forum/index.php/topic,3174.msg19663.html#msg19663 You can ignore the German explanation, Just execute the commands listed in that post. That should fix the problem.

Es gibt in dem Sinne keine Verbindung zu den einzelnen Brick und Bricklets. Du verbindest dich mit der IPConnection zum Brick Daemon, oder zur WIFI oder Ethernet Extension und kannst dann darüber die einzelnen Bricks und Bricklets erreichen. Der Enumerate Callback sagt dir dann welche Bricks und Bricklets du gerade als Stack per USB an oder abgesteckt hast. Einen Stack den du über WIFI oder Ethernet Extension erreichst ist fest und kann sich zur Laufzeit nicht ändern.

You can't, there is no support for this.

IPConnection.CONNECTION_STATE_CONNECTED ist eine Konstante. Die ist immer 1. Den Zustand der Verbindung gibt ipcon.GetConnectionState() zurück. Diesen Rückgabe Wert kannst du dann mit IPConnection.CONNECTION_STATE_* vergleichen, um zu sehen ob die IPConnection *_DISCONNECTED, *_CONNECTED oder *_PENDING ist. ipcon.GetConnectionState() sagt dir nichts über einzeln Brick(let)s aus, sondern sagt dir wie die Verbindung zum Brick Daemon, zur WIFI oder zur Ethernet Extension ist.

Ja. PS: Es heißt PTC, nicht TPC.

You probably have an Ambient Light Bricklet 2.0 and are trying to use an Ambient Light Bricklet (1.0) example. Try these examples instead: http://www.tinkerforge.com/de/doc/Software/Bricklets/AmbientLightV2_Bricklet_Python.html

Ich kann das Problem hier mit einer frischen WIFI Extension 2.0 reproduzieren, habe allerdings noch keine Erklärung dafür. Du kannst das Problem beheben, indem du die Extension auf 2.0.0 und danach wieder auf 2.0.1 flasht. Das Problem ist hier beim Testen nicht aufgefallen, da es verschwindet sobald 2.0.1 einmal erfolgreich geflasht wurde.

Die WIFI Extension 2.0 wird im Prinzip wie ein Bricklet über den Master Brick geflasht. Der Master Brick musst dazu in keinen speziellen Modus versetzt werden. Aber du kannst nur über USB flashen, weil der Master Brick den ESP8266 zum Flashen in einen Bootloadermodus versetzt und dadurch die WLAN Verbindung verloren geht. Daher kannst du die WIFI Extension 2.0 nicht über ihre eigene WLAN Verbindung flashen. Die FW Versionsanzeige ist schon eingebaut, ist nur noch nicht released.

Firmware: WIFI Extension 2.0 2.0.1 Update ESP8266 SDK to version 2.0.0 Add web interface for configuration and status Add RX/TX counters Fix static IP configuration for access point mode Download: WIFI Extension 2.0

Firmware: WIFI Extension 2.0 2.0.1 ESP8266 SDK auf Version 2.0.0 aktualisiert Web Interface für Konfiguration und Status hinzugefügt RX/TX Zähler hinzugefügt Static IP Konfiguration für Access Point Modus repariert Download: WIFI Extension 2.0

6cPiac != 6CPiac

This should just work. I tested it and it does. The only reason I can think of, is that you're using the wrong UID. Can you show a screenshot of the Brick Viewer Setup tab showing your IMU brick 2.0?

That's strange! This error makes no sense for function ID 8. Can you show your C# code?

steppery.SetSteps(distanceyaway) kann nicht darauf warten, dass die Schritte auch wirklich ausgeführt wurden, dass muss du selbst tun. Ein einfache Methode ist nach den SetSteps Aufrufen mit Thread.Sleep (benötigt Imports System.Threading) einfach etwas zu warten, bis die Schritte ausgeführt wurden.

Did you try what I explained in your German version of this thread?

Whats the error message of the NotSupportedException? Are you using the IMU (1.0) examples with a IMU 2.0 or vice versa?

Ich kann diese Fehlermeldungen nicht nachstellen. Ich tue folgendes: In Visual Studio 2015 ein neues Visual Basic Projekt anlegen über Neu -> Projekt -> Visual Basic -> Windows -> Klassischer Desktop -> Konsolenanwendung. Dann nehme ich deinen Visual Basic Code und ersetzte damit den Inhalt der Module1.vb Datei die Visual Studio erzeugt hat. Dann füge ich die Tinkerforge.dll auf dem VB.NET Bindings ZIP als Verweis hinzu. Fertig. Das hat zwar andere Fehler, weil du im Code noch einige Tippfehler drin hast, aber ich bekomme keine Fehler über IPConnection oder BrickStepper.

Wird im Brick Viewer unten auf dem GPS Bricklet Tab bei "Time" Datum und Uhrzeit angezeigt, oder steht da "Unknown"? Blink die blaue LED auf dem GPS Bricklet? Teste mal ein anderes Bricklet Kabel. Teste mal einen anderen Bricklet Port am Brick. Sind in der Buchse am Bricklet oder dem Brick Pins krumm?

Sorry, das mit dem $ifend war mir nicht bekannt: http://docwiki.embarcadero.com/RADStudio/Berlin/de/IFEND-Direktive_(Delphi) Der C1091 Fehler ist ein Compiler Bug: http://qc.embarcadero.com/wc/qcmain.aspx?d=9411 Range Check kann wieder angeschaltet werden. Hier eine verbesserte Version. Die sollte alle Probleme beheben, die in diesem Thread genannt wurden. tinkerforge_delphi_bindings_2_1_13_rc1.zip

Das liegt daran, dass dual_button_register_callback() returned lange bevor du den Knopf wirklich drückst. dual_button_register_callback() legt nur fest welche Funktion aufgerufen werden soll, wenn ein bestimmter Callback auftritt. dual_button_register_callback() wartet nicht darauf, dass der Callback auftritt und deine Funktion aufgerufen wird. Die main() Funktion wartet in der getchar() Funktion während cb_state_changed() Aufgerufen wird. Du kannst getchar() durch ein while (true) Schleife ersetzen und dort regelmäßig alle 10 Millisekunden deine knopf Variable prüfen. while (true) { if (knopf == 1) { ... } if (knopf == 2) { ... } usleep(10000); // Warte 10 Millisekunden } Für usleep muss du noch unistd.h includen. Falls du auf Windows bist, musst du usleep(10000); durch Sleep(10); ersetzen und windows.h includen.