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