[C#] IO16 GetPort über WLAN EXTREM langsam?

[Arnim]

Hallo,

 

in Ermangelung eines Serial-Bricklet realisiere ich das Ganze jetzt über einen 16550 als Puffer an einem IO16.

 

Über USB läuft das Ganze im Prinzip sauber, außer, dass der IO16 nach eine mehr oder weniger langen Zeit plötzlich nicht mehr reagiert - aber das soll jetzt nicht das Thema sein.

 

Binde ich den Brickstapel über WLAN an habe ich plötzlich folgenden Effekt:

 

Der Aufruf eines einzelnen GetPort benötigt plötzlich 200ms(!) und per USB nur wenige Ticks. Alles andere läuft ansonsten wie über USB, nur eben extrem langsam.

 

Ist das ein bekannter Fehler, oder liegt hier bei mir irgendwo ein Wurm begraben? Jemand eine Idee, wo ich suchen könnte?

 

VG, Arnim.

 

PS: Ist das eher ein Thema für den HW-Thread?

[borg]

Wie ist die WLAN Extension denn konfiguriert (AP/Verschlüsselung etc)? Der Power Mode steht nicht zufällig auf Low Power oder?

 

200ms roundtrip-time ist in der Tat ein bisschen langsam.

[Arnim]

Die Extension hängt "ganz normal" im WLAN per WPA2. Ich setze den Power-Mode nicht explizit (das heißt doch, dass Full-Power aniegt, oder?).

 

Ein Zugriff auf ein angehängtes LCD-Bricklet geht auch super schnell (Löschen, komplett neu schreiben in etwa 100 Ticks). Auch das Setzen von Bits am IO16 ist gewohnt schnell, nur eben das GetPort lässt sich ein knappes Lichtjahr Zeit.

 

Ist etwas strange. Ich schätze andere Nutzer setzen ja sicher auch ein IO16 am WLAN unter C# ein? Wie sind da die Erfahrungen?

[photron]

Schreiben auf's LCD und setzen der IO16 Pins ist schnell, weil da in deinem Programm nicht auf eine Antwort über WIFI gewartet wird. WriteLine und SetPort returnen sobald die Daten per Netzwerk rausgeschickt wurden, darum merkst du da die Verzögerung nicht. Auf dem Brick kommt das Ganze dann aber mit Verzögerung an, bzw. wird mit Verzögerung bearbeitet.

 

Bei GetPort muss der Aufruf in C# warten bis die Antwort vom Brick da ist, da merkst du dann die Verzögerung wieder. Soll heißen nicht nur GetPort ist bei dir langsam, sondern das sollte auch alle anderen Getter betreffen, z.B. IsButtonPressed des LCD.

 

Rufst du viele Setter pro Sekunde auf? Es könnte sein, dass du den Eingangsbuffer der WIFI Extension mit Setter Aufrufen auf einem hohen Füllstand hältst und es deshalb länger dauert bis ein GetPort Aufruf eine Antwort bekommt. Ist also GetPort auch dann langsam, wenn dein Programm nur GetPort aufruft oder wird es erst langsam wenn du noch viele andere Funktionen aufrufst? In dem Falle überforderst du sozusagen die WIFI Extension und du solltest versuchen weniger Funktionen pro Sekunde aufzurufen.

[Arnim]

@photron: Danke für die ausführliche Erläuterung. Aber leider kann es daran nicht liegen. Das Ganze ist auch langsam, wenn ich von Hand im Trace durch das Programm laufe. Ich steppe also Zeile für Zeile durch (in humanoidem Tempo) und komme zum GetPort dieser einzelne Aufruf hängt dann 200ms fest und weiter geht's.

[photron]

Hast du mal andere Getter getestet? IsButtonPressed des LCDs oder GetStackVoltage des Masters. Ich erwarte, dass die auch so langsam sind.

 

Bei Settern merkst du die Verzögerung beim Methodenaufruf nicht, weil da nicht auf eine Antwort gewartet wird, sie ist aber da. Das heißt, wenn du beim LCD das Backlight einschaltest solltest du zwischen BacklightOn Aufruf und bis das Backlight wirklich an geht 100ms Verzögerung sehen können (unter der Annahme, dass die Verzögerung auf Hin- und Rückweg gleich ist).

 

Wenn du also nicht durch viele Aufrufe den Eingangsbuffer der WIFI Extensions voll hältst, dann bleibt noch schlechter WIFI Empfang als Erklärung. Du könntest auch mal versuchen die WIFI Extension als Access Point zu konfigurieren und dich dann direkt mir ihr zu verbinden um deinen normalen Access Point aus der Gleichung heraus zu nehmen.

[Arnim]

@photron: Ich habe ganz scharf geschaut, aber die 100ms will ich nicht beschwören. Evtl. muss ich an hier an meiner Eyeball-To-Brain-Schnittstelle tweaken und sehen, ob ich die System.Diagnostics.Stopwatch hier einbinden kann. ;-)

 

Die anderen Hinweise werde ich jetzt mal genauer unter die Lupe nehmen.

[AuronX]

+1 für nerdige .NET-Witze ^^

 

Eine Verzögerung von 100ms wäre sogar mithilfe einer Kamera (die wenigstens > 10FPS bringt, besser >20) die sowohl Bildschirm als auch LCD sieht sichbar zu machen

 

P.S.: Einfach einen anderen Getter zu testen sollte aber zuverlässiger, wenn auch weniger spaßig sein ^^

[Arnim]

Ich habe jetzt von W-Lan nach RS485 gewechselt - so läuft es top.

 

W-Lan werde ich daher nicht mehr weiter untersuchen.

 

Aber das hier ein ziemlicher Overhead zustande kommt wenn Programm und Brick über mehrere Switches kleine Paketchen schieben leuchtet ein.

[AuronX]

Ich fände eine Ursachenforschung noch durchaus spannend ^^

Aber wenn du die nicht machen willst kann ich dich nicht dazu zwingen

[Arnim]

@AuronX: Dir zuliebe - und aus Neugier - habe ich jetzt einfach mal meine drei möglich Verbindungen zum Brick getestet. Identische Software. Identischer Bricks. Einmal direkt am PC per USB, einmal über einen zweiten Brick per RS485 und einmal per W-Lan.

 

Die Zeiten gelten für einen Lesecycle (2x SetPort und 1x GetPort):

 

- USB ca. 1-2ms/C

- RS485 ca. 6-7ms/C

- W-Lan ca. 1200ms/C

 

Der Ping auf das W-Lan-Modul beträgt 2-3ms und die Empfängsstärke am Modul liegt bei ca. -60dB. Der Signalweg ist: PC->Zyxel GBit-Switch->Fritz-Box-7390->Brick. Der Weg erscheint mit jetzt nicht zu ausgefallen. Die Kabelstrecken sind alle GBit.

 

Ganz schön zäh... ist das "Normal"?

[AuronX]

Das ist ja alles sehr komisch. Ich frage mich ob es mit dem langsamen GetPort zusammenhängt das du in einem anderen Thread erwähnt hast (in Kombination mit "ohne LCD").

 

Ich glaube wenn das normal wäre, dann wäre die WiFi-Extension der Top-Rückläufer bei TF