Moin zusammen,

ich versuche gerade, meine Bricks (DC/DC-Modul, Masterbrick, 3 Stepper) unter WinXP in Betrieb zu nehmen. Mit dem Brickviewer konnte ich nachweisen, dass es grundsätzlich geht. Und ich konnte die UID der Bricks ermitteln. Aber auch der Brickviewer hat mit einem Stepper Probleme, sich zu verbinden, wenn der Masterbrick nicht im System und USB an diesen angeschlossen ist. Die anderen beiden werden sofort gefunden.

Nun habe ich unter VisualC 2008 Express das Beispielprogramm zur Initialisierung eines Steppers in Betrieb genommen und bekomme stets ein Timeout, wenn der Stepper das erste Mal antworten soll (ipcon_add_device). Dabei ist es egal, ob ich nur einen oder alle Stepper im System habe. Habe ich nur einen Stepper im System, verwende ich auch die UID, die mir der Brickviewer für diesen Brick angezeigt hat.

Gibt es Ideen, welche Fehler ich gemacht haben könnte.

Vielen Dank

uwet

Hi!

 

Im Brick Viewer sollten immer alle angeschlossenen Geräte angezeigt werden. Habe ich das richtig verstanden, dass der eine Stepper auch wenn er einzelnd per USB angeschlossen ist Probleme hat im Brick Viewer aufzutauchen?

 

 

Ja, einer läßt sich nicht ansprechen, wenn er nicht auf einem Masterbrick sitzt. Aber wenn ich USB an den Masterbrick anschließe, werden alle Bricks erkannt - incl. der Bricklets.

Lass uns erstmal versuchen, dass alle Geräte im Brick Viewer korrekt angezeigt werden. Dein Problem mit dem einem Stepper deutet auf einen USB Defekt hin. Die Bricks wurden von uns per USB geflasht, zumindest zu diesem Zeitpunkt muss USB funktioniert haben. Kann es sein, dass für diesen einen Stepper die Treiber nicht korrekt installiert sind?

 

Bitte schließe mal alle Bricks einzelnd per USB an (hintereinander) und überprüfe im Geräte Manager das die Treiber korrekt installiert sind.

okay, nach der Neuinstallation des Treibers für diesen Brick erkennt auch der Viewer diesen wieder als Einzelgerät.

Das ändert aber noch nichts an der Situation aus dem Beispielprogramm heraus - weiter Timeout.

Wir hatten es mit VisualC++ 2011 getestet. Richte gerade 2008 ein und melde mich bei dir sobald ich mehr weiß.

Sorry hat etwas gedauert.

Also ich habe Visual C++ 2008 installiert und hatte etwas mit Compiler und Linkerproblemen zu kämpfen (stdint.h etc.).

 

Nachdem diese überwunden waren hat er mir eine .exe rausgeschmissen, die meinen Schrittmotor hier ansteuert. Funktioniert also.

Ich habe die aktuell verfügbaren Bindings benutzt und die "example_configuration.c" für das Stepper Brick kompiliert (angegebene UID durch die meines Stepper Bricks ersetzt).

 

(Damit es kompiliert ist es wichtig die unter http://www.tinkerforge.com/doc/Software/API_Bindings.html#c-c genannten Einstellungen durchzuführen.)

 

Ich sehe keinen Grund warum dein Programm das Brick nicht ansteuern können soll wenn es im Brick Viewer auftaucht (sofern die UID korrekt ist, Groß/Kleinschreibung beachten).

Auch nachdem ich das Projekt noch einmal jungfräulich aufgesetzt, die UID kontrolliert, mit dem Viewer verifiziert, diesen disconnectet und auch ein RESET des Bricks gemacht und die Bricks incl. UID getauscht habe, will das Programm dem Brick keine Antwort innerhalb der Timeoutzeit entlocken.

Der Brick ist hinter einem versorgten USB-Hub angeschlossen - nur so als Randinfo. Stecke ich den Brick direkt an, ergibt sich das gleiche Bild.

Eine längere Timeout-Zeit brachte erwartungsgemäß auch keine Verbesserung ebenso wie der Neustart nichts bewirkte.

Mh, schwer zu sagen. Da im brickv jetzt alles funktioniert, scheint der brickd ja zu laufen. Der brickv nutzt zwar Python, aber die Kommunikation läuft ja über herkömmliche Sockets. Ich würde also ausschließen das die nicht richtig funktionieren.

 

Bleiben nur noch die C Bindings selbst übrig. Kannst du mal den buffer in der ip_connection.c direkt in der recv loop ausgeben (Zeile 61)?

 

Ich würde im Moment davon ausgehen das die Daten dort ankommen (da ich einfach keinen Grund sehe warum es nicht funktionieren sollte), dann aber irgendwo in einer der Semaphoren oder so stecken bleiben.

 

Ich würde erwarten das die Nachricht an ipcon_handle_message übergeben wird, dort wird festgestellt das der Typ TYPE_GET_STACK_ID ist, von da gehts an ipcon_add_device_handler und da wird die sem_answer Semaphore freigegeben.

 

Wenn es geht guck doch mal wo es da stecken bleibt, da es bei uns läuft hab ich da gerade keinen Anhaltspunkt woran es liegen könnte.

 

 

 

Unter Win kommt keine Ausgabe des Buffers.

Wir haben dann das Ganze unter Linux kompiliert und auf einem anderen Computer laufen lassen. Dort geht es, die bricks zu connecten.

Also muß ich wohl meinen Rechner verschrotten?! Als letzter Test auf meinem Rechner bliebe dann wohl nur noch, es unter Linux zu probieren

Sehr unwahrscheinlich das es am Rechner selbst liegt. Wird denn die Funktion ipcon_recv_loop überhaupt aufgerufen? Also wenn du mal ein printf direkt oben in Zeile 38 reinmachst.

 

Ansonsten, gestartet wird die recv loop in Zeile 293:

ipcon->handle_recv_loop = CreateThread(
	NULL,
	0,
	(LPTHREAD_START_ROUTINE)ipcon_recv_loop,
	(void*)ipcon,
	0,
	(LPDWORD)&thread_recv_loop_id
);

 

Wird da noch aufgerufen? Wenn nicht, wo bleibt das Programm stehen vorher? Dem Problem sollten wir auf die Spur kommen können, soviel passiert ja gar nicht bis dahin.

Das Programm kommt noch in ipcon_recv_loop an und eine Ausgabe erfolgt auch noch direkt nach dem While. Nach dem recv(...) passiert jedoch nichts mehr.

Die Parameter von recv:

ipcon->s = 4000

(char*)buffer = 0x00a2dfa0 ""

RECV_BUFFER_SIZE = 8192

flags = 0

Mysteriös. Wo steht er denn bei ipcon_add_device (Zeie 339ff)?

 

Kommt er bis zum

if(ipcon_answer_sem_wait_timeout(device) != 0) {

oder steht er schon beim

send(ipcon->s, (const char*) &gsid, sizeof(GetStackID), 0);

?

 

Und kannst du da auch mal die Elemente von GetStackID ausgeben? Um zu gucken ob da alles richtig ist.

Das Programm steht erst bei if(ipcon_answer_sem_wait_timeout(device) != 0) {...

Die Parameter von GetStackID vor dem wait_timeout sind:

stack_id = 0

type = 0xff

length = 14

uid = 0x3033303732303332

 

send(..) geht an socket 0x00000fa0, mit Adr. von GetStackID, Länge 14 und Flags 0; es hat auch 14 Bytes gesendet lt. return.

Echt komisch, sieht alles so weit gut aus. Als length würde ich 12 erwarten anstatt 14, das sollte aber keine Probleme machen. Ich hab mal das Testprojekt was wir hier verwendet haben hochgeladen: http://download.tinkerforge.com/_stuff/project_uwet.zip

 

Bin gespannt ob das bei dir funktioniert. Wenn ja müsste es irgendeine Compilereinstellung o.ä. in deinem Projekt sein sein die zu den Problem führt.

 

Du kannst auch versuchen die Test.exe direkt auszuführen, das sollte auf jedenfall gehen. Wenn die nicht geht liegt das Problem außerhalb des Compilers, da sie bei uns funktioniert. Als UID haben wir 94ANbHiaKXq genommen das sollte die für deinen Stepper Brick sein.

 

Danke! Die Exe läuft problemlos. Es scheint so, als wenn etwas mit den Headern nicht stimmt. Will ich das funktionierende Projekt neu erstellen, fehlt ihm eben der Header stdint.h. Kopiere ich den von mir verwendeten Header in das Projekt, is der Compiler zufrieden, aber das Projekt läuft auch nicht mehr. Das paßt dann auch zu dem zu langen Datenblock. Ich weiß zwar nicht, warum der Header fehlt, aber könnt Ihr mir bitte diesen und zu Sicherheit auch den stdbool.h schicken? Obwohl Linux (gcc) mit dem gleichen Header arbeitet.

Ich hatte bei Visual Studio 2008 auch Probleme mit den Headern.

Hatte auch die Meldung, dass stdint.h nicht verfügbar ist. Habe diesen dann unter http://msinttypes.googlecode.com/svn/trunk/stdint.h heruntergeladen und in das include Verzeichnis verschoben (bei mir C:\Program Files\Microsoft Visual Studio 9.0\VC\include). stdbool.h habe ich nie angepackt, lief wie gesagt auch ohne.

 

Danach konnte ich direkt, ohne meine Projekteinstellungen zu ändern, kompilieren.

 

Wir hatten wie gesagt mit einer neueren Version getestet, da treten diese Probleme überhaupt nicht auf. Vll. ist es einfacher zu update?

 

Grüße,

 

Bastian

So, jetzt kann ich Euer Projekt auch lauffähig compilieren. Eine schwere Geburt.

Vielen Dank für die Hilfe.

Eine Frage habe ich noch:

Gibt es einen tieferen Sinn für die Deklaration einer double-Zahl in ipcon_create (Zeile 293), wenn CreateThread eigentlich DWORD erwartet? Für das Beispiel wäre er jedenfalls nicht ersichtlich, da nirgends weiter verwendet.

Also nochmals vielen Dank

 

gruesse uwet

Eine Frage habe ich noch:

Gibt es einen tieferen Sinn für die Deklaration einer double-Zahl in ipcon_create (Zeile 293), wenn CreateThread eigentlich DWORD erwartet? Für das Beispiel wäre er jedenfalls nicht ersichtlich, da nirgends weiter verwendet.

Oh, das ist ein "Bug". An der Stelle ist das aber natürlich egal, der Wert wird ja nicht benutzt. Wenn ich das nächste mal etwas an den Bindings ändere werde ich das fixen.