+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: UDP Read liest verzögert (/Thread-UDP-Read-liest-verzoegert)
Seiten: 1 2
UDP Read liest verzögert - NoWay - 09.06.2015 09:50
Hallo zusammen.
Ich wende mich hier mit einem verzwickten Problem an euch. Gleich vorab: Ich kann leider nicht die betroffenen VI´s hochladen. Allerdings werde ich versuchen, die "Problemstellen" per Screenshots darzulegen.
Beschreibung:
Ein bestehendes Projekt kommuniziert zwischen PC und Hardware Controller via UDP. Dem zugrunde liegt ein firmeninternes Protokoll, weshalb ich die VI´s nicht posten kann. Das Verfahren ist simples PingPong. Ich schreibe eine Nachricht an den Controller, um z.B. seinen Zustand zu ändern und bekomme gleich darauf eine Antwort, in der der IST Zustand steht (neben weiteren Informationen, die grad nicht von Bedeutung sind).
Das Problem:
Wenn ich die Anwendung starte und über das Userinterface den Zustand ändern möchte, muss der Vorgang durch einen Buttonklick veranlasst werden. Die Daten vom Userinterface werden zusammengepackt und als Nachricht versendet. Diese Nachricht wird dann permanent geschickt. Auf jede antwortet der Controller sofort mit den neuen Werten. Allerdings sehe ich das Anfangs NUR auf dem Wireshark. Erst nach einer mehrsekündigen Zeitspanne kommen die erwarteten Daten am UDP Read Block an. In den ersten 30 Sekunden ist die Zeitspanne noch verhältnismäßig kurz (1-2 Sekunden), schaukelt sich dann aber auf bis zu 8,5 Sekunden hoch, ehe ich die neuen Vorgaben in Labview "sehe".
Das merkwürdige daran ist, dass der UDP Block keinen Fehler meldet, mir aber während dieser Zeitspanne noch die alten Daten herausgibt, obwohl auf dem Wireshark bereits die neuen zu sehen sind.
Das habe ich bisher untersucht:
UDP Read und Write arbeiten in einem VI in zwei parallel laufenden Schleifen. Hinter dem UDP Read sitzt ein Konverter VI, dass mir die Stringnachrichten in typdefinierte Cluster verpackt. Bereits am Eingang des Konverters kann ich via Probes erkennen, dass die zu erwartenden Daten nicht da sind (sie sind aber bereits mit dem Wireshark zu erkennen) und erst viel später dort eintreffen. Dennoch bekomme ich nachwievor die alten Daten, als hätte sich ein Puffer von 8 Sekunden aufgebaut, der erst leergeräumt werden muss. Etwas derartiges ist aber von meiner Seite nicht implementiert: Ich lese einmal via UDP und schicke diese Nachricht hart verdrahtet an das Konverter VI, ohne Queue oder sonstigen Schnickschnack. Ich bin mir also sicher, dass dieses Problem nicht im Konverter liegt sondern bereits beim Lesen der Schnittstelle auftritt. Außerdem lese ich die Schnittstelle nur an exakt einer Stelle aus.
Ich finde keine Erklärung für dieses extreme Verzögerung.
Anbei noch ein paar Screenshots:
[attachment=53321]
Dies zeigt links das UDP Read VI und rechts den Konverter. Da ich bereits weiß, dass die Daten vor dem Konverter nicht "rechtzeitig" da sind, kann ich diesen ausschließen und gehe nicht näher darauf ein. zumal der Konverter ziemlich simpel aufgebaut ist und lediglich ByteArrays per Typecast zuordnet.
UDP read sieht folgendermaßen aus:
[attachment=53322]
Die Anzahl der Wiederholungen ist standardmäßig immer 1. Max Bytes to Read ist auf 1500 festgelegt. Die ankommenden Pakete sind aber deutlich kleiner (ca 220 Bytes).
Das gesamte Konstrukt wird in einer Whileschleife alle 25ms aufgerufen, sodass ein PingPong Datenaustausch alle 25ms stattfindet. Fehlermeldungen werden nicht generiert, Daten bleiben nirgends "stehen".
Hat hier jemand sowas schonmal beobachtet oder kann mir Tipps geben, wie ich diesem Phänomen gezielt auf die Schliche kommen kann? Ich bin mit meinem Latein am Ende -.-"
Gruß
NoWay
RE: UDP Read liest verzögert - NoWay - 09.06.2015 10:52
Nachtrag:
Ich habe nun versucht, mit Semaphoren einen geordneten Ablauf zu generieren, indem Rx und Tx Schleife jeweils aufeinander Warten, bis der andere fertig ist, da ich vermutet hatte, dass der parallele Zugriff auf irgendeine Weise problematisch sein könnte. Das brachte aber keinen Erfolg. Unmittelbar nach Programmstart ist die Verzögerung noch sehr gering und wird dann immer länger.
RE: UDP Read liest verzögert - Trinitatis - 09.06.2015 11:02
(09.06.2015 09:50 )NoWay schrieb: Max Bytes to Read ist auf 1500 festgelegt. Die ankommenden Pakete sind aber deutlich kleiner (ca 220 Bytes).
... und dein Timeout steht auf 1000!
Das heißt, du wartest bei jedem VI-Aufruf mindestens 1s, es sei denn, du würdest die geforderte Byteanzahl lesen, was bei dir nicht der Fall ist.
Gruß, Marko
RE: UDP Read liest verzögert - NoWay - 09.06.2015 11:08
Ich habe an der Stelle bereits experimentiert. Kleine Zeiten bringen keine Verbesserung. Der Verzögerung baut sich dennoch auf.
RE: UDP Read liest verzögert - Trinitatis - 09.06.2015 11:21
... ich hatte überlesen, dass es sich um Verzögerungen bis zu mehreren Sekunden handelt.
Hast du schonmal versucht, dein Lese-VI testweise abzuspecken?
Ich weiß z.B. nicht, was diese IP nach String-Funktion intern so treibt.
Du kannst ja bis auf die reine Lesefunktion schrittweise alles rausschmeißen.
Gruß, Marko
RE: UDP Read liest verzögert - NoWay - 09.06.2015 11:49
Gerade getestet. Da ich die IP als string für fast alle anderen Bestandteile des Programms benötige, habe ich sie durch eine Konstante ersetzt und dann das "nackte" UDP Read Element verwendet. Die Verzögerung baut sich nachwievor auf. Interessanterweise kann ich das im Wireshark nachvollziehen. Hatte mir auf einen bestimmten Zustand einen Breakpoint gesetzt und den Zustand getriggert, als die Verzögerungen deutlich spürbar waren. Resultat: Mein Programm stand, aber im Wireshark wurde noch eine Zeitlang weitergequatscht. Muss mir das jetzt im Detail angucken. Ich vermute, dass ich mit dem zusammenrechnen der Zeiten auf die Verzögerung komme, die sich da aufbaut.
Puffert Labview die ein- und ausgehenden Daten? Das würde heißen, dass ich eventuell zu schnell lese/schreibe.
RE: UDP Read liest verzögert - jg - 09.06.2015 13:24
Laut Hilfe solltest du nicht mehr als 548 Byte in ein UDP-Paket packen/lesen. Mit der 1 Sekunde Wartezeit sehe ich nicht das große Problem, im Gegensatz zu VISA-Read oder TCP/IP Read gibt UDP-Read ein komplettes Paket (auch wenn es kleiner als 548 Byte ist) zurück, wenn es empfangen wurde.
Im Screenshot sieht man, dass du im Read-VI eine For-Schleife verwendest. Wie groß ist "# Repetitions"? Könnte sich beim x-ten Warten, wenn vielleicht gerade gar kein Telegramm zum Lesen da ist, diese Wartezeit aufbauen?
Ohne Garantie, aber ja, ich denke, irgendwo wird noch ein interner Empfangspuffer verwendet, entweder in LabVIEW oder sogar davor im TCP-Stack.
Gruß, Jens
RE: UDP Read liest verzögert - flowschi - 06.04.2017 07:51
Guten morgen!
Ich bin bei der Suche nach unserem Problem auf diesen Thread gestoßen.
Wir haben GENAU das gleiche Problem. UDP, LV 2016,... LV Output passt nicht mit Wireshark überein. Eine genaue Verzögerung in Sekunden haben wir noch nicht untersucht.
Ist denn hier was bei rausgekommen? Gab es eine Erklärung oder Lösung?
Danke!
RE: UDP Read liest verzögert - GerdW - 06.04.2017 08:10
Hallo flowschi,
Zitat:Gab es eine Erklärung oder Lösung?Die hatte Jens doch gegeben: es wird irgendwo einen internen Buffer geben, wahrscheinlich im TCP/UDP-Stack.
Ich hatte bisher keine Probleme mit Verzögerungen bei UDP-Botschaften - solange man die Botschaften schnell genug ausliest…
Zitat:LV Output passt nicht mit Wireshark überein. Eine genaue Verzögerung in Sekunden haben wir noch nicht untersucht.Über welche Größenordnung reden wir jetzt eigentlich?
RE: UDP Read liest verzögert - flowschi - 06.04.2017 09:10
Für mich ist das keine Antwort.
Zu 99% läuft die Kommunikation, aber falls es zum Problem kommt, kommen wir auch nicht raus ohne die Verbindung zu schließen.
Wir senden 8 Bytes, bekommen 20 ms später die Antwort von 42 Bytes. In dieser Antwort erwarten wir einen Zähler - aber wir bekommen den alten Wert. Das ganze wird zyklisch wiederholt für 300 ms. In Wireshark bekommen wir auch in allen 7-8 Frames von 42 Byte den richtigen Zähler zu gesicht - in LabVIEW sehen wir allerdings in allen Frames den alten. Und je nachdem wie schnell wir mit Breakpoints durchsteppen, kommt der neue Zähler dann irgendwann.
Von der Datenmenge sind wir weit entfernt von dem, was der Windows Buffer als Standard zulässt. Im Empfangspuffer liegen normalerweise nie mehr als diese 42 Bytes, da sie immer nur als Anwort auf unseren Request gesendet werden.