photron

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.

Du kannst das über einen globale Variable machen. Du kannst aber auch den User Data Pointer der Callbacks nutzen: #include <stdio.h> #include "ip_connection.h" #include "bricklet_dual_button.h" #define HOST "localhost" #define PORT 4223 #define UID "XYZ" // Change XYZ to the UID of your Dual Button Bricklet // Callback function for state changed callback void cb_state_changed(uint8_t button_l, uint8_t button_r, uint8_t led_l, uint8_t led_r, void *user_data) { (void)led_l; // avoid unused parameter warning (void)led_r; // avoid unused parameter warning // EDIT: Pointer auf lokale Variable in main() aus User Data Pointer casten int *knopf = (int *)user_data; if(button_l == DUAL_BUTTON_BUTTON_STATE_PRESSED) { printf("Left button pressed\n"); // EDIT: 1 an lokale Variable in main() zuweisen, dazu Pointer dereferenzineren *knopf = 1; } else { printf("Left button released\n"); // EDIT: 0 an lokale Variable in main() zuweisen, dazu Pointer dereferenzineren *knopf = 0; } if(button_r == DUAL_BUTTON_BUTTON_STATE_PRESSED) { printf("Right button pressed\n"); } else { printf("Right button released\n"); } printf("\n"); } int main(void) { // Create IP connection IPConnection ipcon; ipcon_create(&ipcon); // Create device object DualButton db; dual_button_create(&db, UID, &ipcon); // Connect to brickd if(ipcon_connect(&ipcon, HOST, PORT) < 0) { fprintf(stderr, "Could not connect\n"); return 1; } // Don't use device before ipcon is connected // EDIT: lokale Variable anlegen int knopf = 0; // Register state changed callback to function cb_state_changed dual_button_register_callback(&db, DUAL_BUTTON_CALLBACK_STATE_CHANGED, (void *)cb_state_changed, // EDIT: Pointer auf lokale Variable als User Data Pointer an den Callback geben (void *)&knopf); printf("Press key to exit\n"); getchar(); dual_button_destroy(&db); ipcon_destroy(&ipcon); // Calls ipcon_disconnect internally return 0; }

Das ist schon eingeplant. Eine einfache Methode das Problem bis dahin zu verhindern, ist den grünen Stecker einfach in der Buchse stecken zu lassen.

In der vorherigen Version der Bindings konnte folgender Fehler beim Connect auftreten: "This protocol version is not supported exception" Dies ist in dieser Version jetzt behoben. tinkerforge_csharp_bindings_2_1_11_fix2.zip

Ja.

Hast du die Akkus an der Step-Down Power Supply am grünen 5V Ausgang, oder am schwarzen 6-27V Eingang angeschlossen? Von deiner Beschreibung her hast du die Akkus am 5V Ausgang angeschlossen und damit 8V auf die 5V Leitung gegeben. Das vertragen die Bricks nicht.

Now I see what you needed those MQTT additions for Very nice!