Jump to content

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


Recommended Posts

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

+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 :D

 

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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"?

Link to comment
Share on other sites

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 :D

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...