remotecontrol

You are using this public class Init { ... static IPConnection ipcon; static BrickServo servo; ... static void connection() { ... IPConnection ipcon = new IPConnection(); BrickServo servo = new BrickServo(UID, ipcon); .. Change it to public class Init { ... static IPConnection ipcon; static BrickServo servo; ... static void connection() { ... ipcon = new IPConnection(); servo = new BrickServo(UID, ipcon); .. Otherwise you assign the BrickServo object to a local variable which visible in the method only. And the static member servo is still null.

Kannst Du den Stacktrace der Exception noch dazu packen? Ich erzeuge die Devices immer erst nach dem Connect (allerdings generisch über den enumerate()). Das wäre dann diese Reihenfolge: ipcon.connect(host, port); BrickServo servo = new BrickServo(UID, ipcon); Ob das aber was ändert habe ich nicht ausprobiert. Die übergebene UID ist korrekt?

In der Doku der WIFI Extension steht dann habe ich das wohl missverstanden: das definiert dann nur die mögliche Reihenfolge der Extensions, nicht die Position der Extension. Der "Master" darin hat mich etwas verwirrt.

Hallo Admins, ich habe kleine Korrekturen in der IPConnection und der Inline-Doku des BrickServo gemacht (siehe Anhang). In der IPConnection sind einige Compiler-Warning entfernt, wichtig ist im disconnect aber sowas: anstelle von try { if(socket != null) { socket.close(); socket = null; } } catch(java.io.IOException e) { e.printStackTrace(); } nutze ich bei mir try { if(socket != null) { socket.close(); } } catch(java.io.IOException e) { e.printStackTrace(); } socket = null; Denn der socket.close() kann fehl schlagen, wenn das Netzwerk zusammenbricht. Dann wird der socket nie wieder auf null gesetzt. Analog für die Streams. Ich weiss nicht, wie Ihr mit Vorschlägen für Code-Anpassungen umgeht, darum mal als Attachment. IPConnection.java BrickServo.java

Suchst Du sowas: http://www.tinkerforge.com/doc/Timeline.html? Und eine Wunschliste gibt es noch: http://www.tinkerunity.org/wiki/index.php/DE/Produkt_Wunschliste Viele Grüße

Ich hab's auch noch mit meinem 2. Stack ausprobiert: klappt dort auch nicht. Oben geht, sogar die Reihenfolge unten Master -> Servo -> Extension. Aber unter dem Master geht nicht.

Hallo, ich habe leider schon wieder ein Problemchen: setze ich die WIFI Extension unter den Master, leuchtet die blaue Diode, aber die Gelbe nicht. Im Brickv wird die Extension nicht angezeigt. Setze ich die Extension aber auf den Master klappt alles. Laut Doku sollte direkt drunter oder direkt drüber klappen. Bei mir geht aber nur direkt drüber - ist das normal? (Alles auf aktuellster Firmware 2.0.1).

5,5A würde ich als ausreichend bezeichnen, das Risiko der Überlastung wäre aber gegeben - stimmt. Wenn man die Variante mit 2x3 wählt, dann reicht es aber, um den maximalen Strom für jeweils drei Optokoppler zu übertragen.

Die "Reproduzierbarkeit" des Aufhängens des Stacks ist nicht mehr gegeben. Ich hab es noch 2x geschafft innerhalb von 1 Stunde probieren. Davor war es nach 10-20 Sekunden probieren reproduzierbar. Mein Fazit: der WLAN Fix hat eine deutliche Verbesserung gebracht. Es scheint aber noch ein versteckter Bug vorhanden zu sein, der sich jedoch nicht so oft zeigt und ich bekomme ihn nicht reproduziert.

Ich muss leider mitteilen, dass das Problem nicht gelöst ist: mein Stack hängt sich immernoch auf an und zu auf, aber es wird deutlich schwerer, dass zu erzeugen. Wenn das Relais alle 1-2 Sekunden einen Monoflop macht und ich parallel dazu mit manueller Steuerung das Servo bewege bootet der Stack irgendwann neu. Vor allem zuckt das Servo sehr stark (bleibt stehen), wenn das Relais ein ist. Ich werde mal versuchen, die Commandfolgen mit Timing aufzuzeichnen - dauert aber etwas. Einen Deadlock in der Anwendung würde ich ja verstehen, aber ein Reboot des Stack ist eigenartig. Was mir auch aufgefallen ist: das Auslesen von Spannung / Strom dauert teilweise über 80ms, d. h. die Response kommt nicht in 6-7, sondern in über 80ms. Ist der Stack zu stark belastet? Mit Firmware Version 1 hatte ich diesen Effekt nicht so deutlich.

Ich habe noch nicht mit der 2.0.1 getestet. Dazu komme ich erst Donnerstag oder Freitag.

Ich habe - ganz unten: Step Down Power Supply - drüber Master - drüber Servo - oben WLAN Ext. Das Relais hängt am Master. Im Beispiel scheint hier keine Step-Down-Power Supply dran zu sein (Voltage ist 0). Diese Stelle hier: Ist schon ein "Zucken". Das müsste gleichverteilt kommen. Wenn sowas bei mir passiert dauert es bei mir nicht lange und der Stack bootet neu. Über meine GUI konnte ich das in wenigen Sekunden reproduzieren. Mit der immer konstanten Rate de Servos im Testprogramm musste ich öfter probieren, bis ich eine Zeiteinstellung gefunden habe, bei der es überhaupt passiert.

Noch ein kleiner Tippfehler oben: der 2. Netzwerkthread verarbeitet die Statuscommands mit Response, keine Servocommands.

Ich hab's extrahiert! Anbei das ZIP mit dem Java-Code. Dort gibt es unter src/bricktest/Main.java die Anwendung hier ist der Connect leicht zu finden. Der ServoThread.java konfiguriert das Servo. Aktuell hängt am PIN 2 (von 7) das Servo. Die Anwendung startet 3 weitere Threads - 1. Thread verarbeitet die Servo-Commands die ohne Response sind - 2. Thread verarbeitet die langsameren Servo-Commands die mit Response sind - 3. Thread 'füttert' Thread 1 mit Servo Befehlen - dazu kommt der main-Thread der den 2. Thread mit Status Befehlen und Relais Befehlen füttert. Warum so viele Threads: eine GUI läuft asynchron über Event-Handler und nie Synchron zu zyklischen Threads. Das habe ich hier versucht, zu simulieren. Bei mir führt das in kurzer Zeit zu einem Timeout und Reboot des Stacks. Der Timeout könnte auch ein Threading Problem sein, aber dann sollte der Stack nicht neu booten - oder? BrickTest.zip

Das mit dem "in ein Programm packen" dauert etwas, wenn ich's heute nicht mehr hinbekomme... Man merkt aber deutlich: - steuere ich das Servo hin und her und "parallel" dazu wird alle 2s Spannung/Strom vom Master ausgelesen, läuft es flüssig - kommt zusätzlich nach dem Auslesen von Spannung/Strom ein setMonoflop(), dann "hakt" das Servo in und recht schnell bekomme ich eine TimeoutException z.B. im getStackVoltage() und der Stack bootet neu. - Das Relais schaltet nur eine Leuchtdiode

Kleiner Zusatz: - auch im normalen Betrieb des Servo lese ich in einem separaten Thread schon alle 2 Sekunden Spannung und Stromverbrauch vom Master aus, das scheint keine Probleme zu machen - kommt hier das Setzen des Quad-Relais hinzu (seriell nach Auslesen der Spannung, aber theoretisch parallel zum Steuern des Relais), hängt sich der Master auf. Auf Client-Seite bekomme ich erst eine TimeoutException und dann eine NotConnectedException. Ich werde jetzt probehalber alle Commands wieder serialisieren in einem Thread.

Ich habe jetzt alle Bricks und Bricklets auf Protokoll 2.0 aktualisiert - puh, aber ging soweit. Jetzt habe ich leider arge Probleme im Betrieb. Mein Teststack besteht aus - Master 2.0 mit Step-Down-Power Supply + WLAN Ext. - Quad Relay - Servo Brick mit nur einem Servo Steuere ich das Servo Brick einzeln => alles OK. (Es kommen ca. 10-15 Servo-Befehle pro Sekunde) Gebe ich aber zusätzlich alle 2 Sekunden einen Monoflop Impuls auf das Quad-Relais (Thread 1) und sende parallel dazu die Servo-Requests bootet der Stack nach kurzer Zeit neu (kann ich in wenigen Sekunden herbei führen). Booten bedeutet: die LED-Reihe leuchtet auf und die WLAN Ext. connected sich neu. Mit API 1.0 hatte ich das nicht. Die Servo-Requests laufen bei mir in einer Queue seriell ab. Aber ein anderer Thread sendet die Quad-Relais Befehle. Ich hatte in 1.0 die Synchronized-Blöcke geprüft und das sah OK aus. Die write() Befehle der IP-Connection schließen sich eh aus. Was ist hier in 2.0 anders? Was kann den Master dazu bringen, neu zu booten?

Hallo Administratoren, als Gedankenansatz ein Vorschlag für eine weiteres Relais-Bricklet (Abwandlung des Quad-Relais): aktuell nutze ich die Quad-Relais so, dass sie entweder Plus oder Minus durchschalten. Wenn 4 Kanäle zu schalten sind, muss ich somit 4x den Plus durchschleifen, quasi eine Brücke von PIN 1 auf 3 auf 5 auf 7; Ausgänge sind dann auf 2,4,6,8 => mühselige Verkabelung wenn es nicht notwendig ist, dass alle 4 Kanäle getrennte Spannungen schalten. Auf der Platine des Relais wäre genügend Platz für 6 oder 7 Optokoppler. Man könnte somit die 8 Kontakte auch so belegen, dass z. B. PIN 1: "Eingang" PIN 2-8: "Ausgang" ist: ergibt ein 7-fach Relais. Oder PIN 1: "Eingang" PIN 2-4: "Ausgang" PIN 5: "Eingang" PIN 6-8: "Ausgang" ergibt ein 2x3-fach Relais. Die API des Quad-Relais passt auch dazu, da eh eine Bitmaske benutzt wird.

OK, dann werde ich sicherheitshalber den Servo-Stecker vom Fahrtregler mal manipulieren.

Bei Delphi muss ich eigentlich passen, aber diverse Foren sagen, dass es auch sowas wie ein "setsockopt" gibt, ähnlich wie in C, z. B. http://www.delphipraxis.net/169249-tidtcpclient-keine-verzoegerung-beim-senden-der-daten.html. Sowas schon probiert?

Hallo, in der Doku des Servo-Bricks ist ein großer Warnhinweis, dass bei ESC mit BEC die Anschlüsse des Servosteckers abgeklemmt werden müssen: http://www.tinkerforge.com/doc/Hardware/Bricks/Servo_Brick.html#brushless-motoren-mit-escs-verwenden. Gilt das generell für alle Fahrtregler mit BEC? Es gibt nämlich nur noch wenige ohne diese Funktion. In der Doku ist aber speziell die Rede von ESC für Brushless Motoren. Wo ist der Unterschied? Ich habe zwei Fahrtregler mit BEC und kleinere "normale" Motoren angeschlossen, alles läuft über ein Akku. Bisher hat's gehalten .

Ich habe jetzt auch nochmal einen Test von einem 2. Rechner aus gemacht, mit Binding 1.x: Auf dem Zielrechner läuft der Brickd und der Stack ist per USB angeschlossen. 2. Rechner greift über LAN/WLAN auf den Zielrechner auf Port 4223 zu: ist auch verzögert, wenn TCP_NODELAY fehlt; der Effekt liegt also nicht an der WLAN Extension.

Kann ich machen, schaffe ich heute aber nicht mehr.

Wichtiger Nachtrag (hatte ich vergessen zu testen): Der socket.setTcpNoDelay(true) behebt scheinbar das Problem! Dann laufen alle Requests in 5-6ms.

Mit dem Delay 5000 sieht es ähnlich aus, wie bei Dir (6-10ms for get+set). Sieht die Schleife aber so aus (delay 100ms), for(int i = 0; i < 100; i++) { Thread.sleep(100); start = System.currentTimeMillis(); int value = iqr.getValue(); iqr.setValue(~value); end = System.currentTimeMillis(); System.out.println("time: " + (end - start)); } Dann ändert sich der Output dramatisch: Noch etwas gespielt: 5000ms Sleep vor get+set => 5-10ms Response 200ms Sleep vor get+set => 5-10ms Response 150ms Sleep vor get+set => 40-50ms Response (Sleep + Response ~ 200ms) 100ms Sleep vor get+set => 100ms Response (Sleep + Response ~ 200ms) Das scheint immer in Summe auf 200ms rauszulaufen. Alles unter 200ms verzögert sich. geht auch mit Zwischenwerten (130ms Sleep).