Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - photron

Pages: 1 ... 161 162 [163] 164 165
2431
Loetkolben, wie gesagt ist das kein Fehler und die Meldung daher keine Fehlermeldung :)

Zu der 20 Frage:

Code: [Select]
$ python -c 'print str(20.00)'
20.0

Wenn du da ein spezielles Ausgabeformat brauchst dann kannst du einfach das Python Script anpassen. Da du eh schon aus

Code: [Select]
print('Temperature: ' + str(temperature) + ' °C')
den Text entfernt hast kannst du das Beispiel ja auch noch weiter anpassen. Immer 2 Nachkommastellen bekommst du so:

Code: [Select]
print('%.2f' % temperature)

2432
Ich werde die Meldung entfernen, den sie hat keinen Mehrwert und stiftet nur Verwirrung wie dieser Thread beweist :)

Außerdem werden Callbacks/Antworten mit unbekannter Function ID eh schon stillschweigend ignoriert.

2433
Ja, ist ein Masterbrick mit 3 verschiedenen Bricklets.

Verstehe aber (noch) nicht. Habe nur das Samplescript angepasst (Meine UID und Textanpassungen) und dann laufen lassen?

Wo sollte man was "adden" muessen?

Du musst da nichts "adden", UID ändern und Beispiel muss funktionieren, tut es ja auch :)

Die Meldung deutet nicht auf ein Problem oder Fehler hin, sondern nur das die IPConnection etwas unerwartetes empfangen hat und es ignoriert hat.

2434
Die Meldung bedeutet, dass die IPConnection eine Nachricht mit Function ID 8 (das ist der Temperature.CALLBACK_TEMPERATURE) vom Stackteilnehmer 2 (das wird wohl das Temperature Bricklet sein) erhalten hat. Aber es kennt keinen Stackteilnehmer 2, daher "unknown Stack ID".

Hast du den Brick Viewer auf und den Tab für das Temperature Bricklet aktiv? Dann hat der Brick Viewer den Temperature.CALLBACK_TEMPERATURE Callback für das Bricklet aktiviert und es sendet Callbacks.

Wenn du nun dein Script startest dann gibt es ein kleines Zeitfenster zwischen der Erzeugung der IPConnection und dem add_device Aufruf. In dieser Zeit empfängt die IPConnection schon eingehende Nachrichten kennt aber das Temperature Bricklet noch nicht.

Du kannst diese Meldung vermeiden indem du brickv oder wer auch immer den Temperature.CALLBACK_TEMPERATURE Callback aktiviert hat schliesst. Oder du kannst die Schleife in das Python Script einbauen, so dass du nicht immer die IPConnection neu erstellst.

Aber eigentlich könnte ich diese Meldung auch aus allen Bindings entfernen. Callbacks/Antworten von unbekannten Devices werden eh ignoriert.

2435
Ja, das Problem von Short Reads ist mir auch schon aufgefallen. Es steht auch auf meiner TODO Liste. Und ja im Moment arbeiten alle Bindings so.

2436
EDIT: egal was ich dazwischenschreibe es muss etwas dazwischen. Aktuell steht 1µs dazwischen.

Es wird dann auch ein usleep(0) tun. Der Punkt ist dann nicht das Warten an sich sondern, dass das usleep() dazu führt dass der Scheduler einen anderen Prozess dran nimmt. Warum auch immer das einen Unterschied macht.

Du sprichst von einem embedded Gerät. Testest du das Programm auch gerade dort, oder auf einem normalen Desktop Rechner?

Du hast noch nicht gesagt welche C Bindings Version du verwendest und ob das Problem auch mit der aktuellen Version 1.0.5 auftritt.

2437
Nein.

Der RecvLoop liest alles was auf dem Socket ankommt und ruft damit HandleMessage() auf. HandleMessage() unterscheidet dann verschiedene Messages:

- AddDevice Antworten werden ausgewertet und das entsprechende Device aktualisiert mit den Informationen über Name, Stack ID etc.
- Callback Antworten werden in die callbackQueue gesteckt
- Andere Nachrichten für bekannte Devices werden in deren entsprechenden answerQueues gesteckt

Der CallbackLoop nimmt Callback Antworten aus der callbackQueue und ruft die entsprechenden Callback Funktionen auf, falls solch eine vom Benutzer registriert wurde.

Getter Aufrufe für Devices warten maximal 2,5 sec bis in ihrer answerQueue etwas angekommen ist.

2438
Beide Threads laufen durch. RecvLoopFlag ist normalerweise True und wird beim destroy auf False gesetzt, damit man die Threads sauber abbrechen kann. Also steht da im Normalbetrieb ein while(True). Dass du im Debugger da nur was passieren siehst wenn du Devices ansteckst ist erwartet. Beim Anstecken schickt dir brickd eine Enumerate Message. Der socketStream.Read() Aufruf blockiert bis Daten zu lesen sind. Also steht der Thread die meiste Zeit in der Read() Methode wenn keine Daten übertragen werden.

2439
Es muss auch ohne die sleeps funktionieren und das tut es hier auch. Ich hatte das vorgeschlagen weil jemand ein ähnliches Problem hatte und ihm sleeps geholfen haben. Das war allerdings vor meiner Zeit.

Tritt das Problem auf Linux, Windows oder Mac OS auf?

Tritt das Problem auch mit der aktuelle Version 1.0.5 der C Bindings auf?

Nur wenn ich das Problem reproduzieren kann kann ich es auch beheben :)

2440
Der RecvLoop läuft dauerhaft, liest alles was am Socket ankommt und behandelt es passend. Der CallbackLoop ist dafür da die Callbacks auszuführen, so dass man aus Callbacks heraus auch noch Getter der Devices aufrufen kann. Würden der RecvLoop die Callbacks ausführen würde dieser ja in der Zeit keine eingehenden Packages mehr annehmen können und wir hätten ein Deadlock, da die Antwort des Devices auf den Getter Aufruf nicht gelesen würde.

Das ganze kommuniziert miteinander über thread-sichere Queues.

2441
Das wäre in der Tat eine Möglichkeit Javascript Bindings zu machen. Aber warum so kompliziert? Wenn ich in Javascript schon WebSocket habe dann kann ich auch gleich von Javascript aus direkt mit brickd reden.

2442
Das Problem ist jetzt auch in Version 1.0.5 der C Bindings behoben.

2443
Software, Programmierung und externe Tools / Re: [C#] Callbacks
« on: May 08, 2012, 10:12:24 »
Änder mal

Code: [Select]
private Device lcd;
in

Code: [Select]
private BrickletLCD20x4 lcd;

2444
Wenn du WebSockets verwendest hast du aber auch ein PHP Programm auf dem Server das dauerhaft (zumindest länger) läuft und dann kannst du in der Schleife die die Clients bedient auch zwischendurch mal dispatchCallbacks() aufrufen und alles ist gut :)

2445
Du meinst, dass das erste ipcon_add_device für das TemperatureIR funktioniert die nachfolgenden aber fehlschlagen?

Ich hab das hier gerade mal getestet und bei mir funktioniert das ohne Probleme unter Linux mit den C Bindings in Version 1.0.5 (von gestern: http://download.tinkerforge.com/bindings/c/tinkerforge_c_bindings_1_0_5.zip).

Hast du das Problem unter Windows oder mit einer alten Version der C Bindings?

Hilft es wenn du zwischen den ipcon_add_device Aufrufen ein sleep von 1 sec einbaust?

Pages: 1 ... 161 162 [163] 164 165