+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Datenkommunikation (/Forum-Datenkommunikation)
+---- Thema: TCP und dessen Header (/Thread-TCP-und-dessen-Header)
Seiten: 1 2
TCP und dessen Header - Ragdar - 20.07.2009 16:18
Hallo LVF,
ich hab Probleme mit TCP/IP. Ich habe einen Schieberegler von 0 bis 14.000 der +/- 0.1 eingestellt werden kann. Als Hintergrund Programmierung steht eine Event-Case die bei Wertänderung des Schiebereglers, einen Befehlscode generiert und diesen in eine Queue schreibt.
Die Queue wird dann alle 100 ms ausgelesen und Befehl für Befehl über die Schnittstelle übertragen - TCP/IP von LabVIEW.
Das Problem ist, wenn ich jetz den Schieberegler von 0 auf 10.000 setze (durch hochschieben), werden soviele Befehlscodes erzeugt dass mir die Kommunikation zusammenbricht. Damit mein ich - sie wird ewig langsam und braucht ewig bis der aktuelle Wert sich einpendelt.
Ich nehme an, dass der Overhead jedes kleinen Datenpakets die Verbindung so extrem beansprucht - dass Sie einfach langsam wird.
Mit anderen Schnittstellen wie IEEE 488 oder RS 232 besteht das Problem nicht - obwohl bei RS 232 die Datenrate bei 9600 baud und bei TCP bei über 200.000 baud liegt.
Was kann man dagegen tun? Wie arbeitet ihr mit TCP?
Gibts eine Möglichkeit der Event zu sagen dass er nur den losgelassenen Wert des Sliders als Event sieht oder dass der Slider nur alle X Sek oder sowas ein Event erstellt?
Danke im voraus
TCP und dessen Header - eg - 20.07.2009 16:27
Ich würde entweder die Inkrementierung des Controls vergrössern oder gar beim Mouse Up Event die Daten erst abschicken.
TCP und dessen Header - schrotti - 20.07.2009 22:21
Wie wärs, wenn du nicht alle 100ms ein Datenpaket sendest sondern alle 100ms den aktuellen Wert des Schieberegisters sendest? Jetzt ist so, dass du hunderte Datenpakete erzeugst und erst mal in einer Queue parkst. Wenn es 100 sind, dauert es auch 10 Sekunden, bis alle Elemente der Queue versendet sind. Da spielt es überhaupt keine Rolle, ob du 10 Brieftauben pro Sekunde oder ein Gigabit-Lan verwendest.
Oder eben wie eq erst eine Paket senden, wenn du die Maustaste losläßt. Oft geht das aber eben nicht.
TCP und dessen Header - Ragdar - 21.07.2009 06:29
' schrieb:Wie wärs, wenn du nicht alle 100ms ein Datenpaket sendest sondern alle 100ms den aktuellen Wert des Schieberegisters sendest? Jetzt ist so, dass du hunderte Datenpakete erzeugst und erst mal in einer Queue parkst. Wenn es 100 sind, dauert es auch 10 Sekunden, bis alle Elemente der Queue versendet sind. Da spielt es überhaupt keine Rolle, ob du 10 Brieftauben pro Sekunde oder ein Gigabit-Lan verwendest.
Ne, ich arbeite allle 100 ms die komplette Queue ab. Sprich sind 100 Elemente drin, mach ich 100 mal Write / Read.
Und das nur mit loslassen ist auch so ein Problem, das wohl leider nicht geht :/
Increment ist auch eher schlecht, da der User durch den Slider den "Groben Wert" einstellt und dann durch INC / DEC Button auf einen Exakten Wert sich ranarbeitet.
TCP und dessen Header - MichaDu - 21.07.2009 10:26
schrotti hat recht. Es müsste doch ausreichen, wenn du den aktuellen Wert des Schiebereglers überträgst. Ist der TCP-Socket in der Reglerschleife oder hast du eine separate TCP-Read/Write-Schleife?
Du könntest sonst eine separate TCP-Schleife verwenden und über eine lokale Variable den Wert übergeben, dann wärst du auch unabhängig von anderen Verzögerungen und könntest auch andere Werte sammeln und gemeinsam alle 100ms übertragen.
TCP und dessen Header - RoLe - 21.07.2009 11:03
ev. würde ein Wait in dem EventCase reichen. (50-100ms)
Gibt jedenfalls weniger Events, und der Benutzer merkt nicht so viel.
.. und das "Lock Frontpanel..." sollte EIN sein.
TCP und dessen Header - Ragdar - 22.07.2009 06:23
Ich habe mal die Kommunikation mit NI Spy mitgeschnitten. Also ich benutze VISA Write / Read für TCP/IP. Ich habe X Befehle die ich in einer Schleife Stück für Stück Schreibe und die Antwort lese.
Wie man sieht, geht es ab und an sehr schnell die Daten zu senden / lesen und dann ist mitten drin mal wieder die Zeit um mehr als Faktor 10 länger. Woher kommt das? Genau deswegen is die Verbindung auch so extrem langsam...
TCP und dessen Header - rolfk - 22.07.2009 07:48
Also warum willst Du die Ganze Queue jeweils senden? Einmal pro 100ms (oder 50 oder auch 10) den letzten aktuellen Wert (sofern vorhanden) wäre doch sicher auch nicht schlecht.
Zu den Delays: Windows ist ein Multitasking/Multihtreading System und es entscheidet ganz alleine wann es welchem Prozess wieviel Prozessorleistung zuteilt. Das kann und bewirkt auch, dass ein Prozess (hier die LabVIEW Applikation) geregelt für einige ms gar nicht zum Zuge kommt, etwa weil der Netzwerk Stack durch einen Interrupt ankommende Daten an den Windows Kernel signalisiert, die verarbeitet werden müssen, oder weil die Harddisk geflusht wird, oder, oder, oder.
In alten Pentium Zeiten war die Regel, garantierte Reaktionszeiten in einer Application kleiner als 100ms sind nicht realistisch zu erwarten, auch wenn es in den meisten Fällen in wenigen ms gut geht.
Heutzutage met Dual Cores etc. ist das etwas weniger extrem, aber Windows ist kein Realtime System und kann das auch gar nicht sein.
Rolf Kalbermatter
TCP und dessen Header - Ragdar - 22.07.2009 08:47
Das kann nicht sein, Rolf.
Nochmal kurz:
Ich habe eine Event-Schleife - die bei Benutzerereignisse (z.B. Taster oder Regler) diese interpretiert und in einen Geräte-Code umwandelt. Der Code wird in eine Queue geschrieben und gesammelt. Je nachdem wie schnell und oft der Benutzer Werte ändert - umso mehr Codes laufen im Queue auf.
Parallel dazu läuft eine Schleife.
Die Schleife ließt ständig wichtige Statusregister vom Gerät aus und zeigt diese auf der Oberfläche an. Zusätzlich werden in der Schleife am Ende alle Elemente in der Queue zum Gerät geschrieben.
D.h.:
Meine Schleife zeigt ohne User-Events meinen Gerätestatus an. Ein Schleifendurchlauf (mit Waiting) dauert ca. 100 ms. Pro Sekunde erhalte ich somit 10 mal den kompletten Status des Gerätes auf dem Panel (Wichtig für Strom und Spannungsüberwachung).
Ändert der Benutzer jetzt Einstellungen, so wird in der Schleife zusätzlich der Inhalt der Queue zum Gerät geschrieben. Jeder Schreib-Lese Zyklus dauert zw. 3 und 10 ms. Was kaum zu Geschwindigkeitseinbusen führt - auch wenn mal 20 Werte in der Queue stehen (durch schnelle Slider Änderung).
So:
Wenn ich mein Gerät an RS 232 anschließe mit einer Übertragungsrate von 9600 Baud - Läuft das Programm um sehr viel schneller als mit TCP/IP. Und egal ob ich USB, RS 232, IEEE 488 oder Profibus benutze - die Schreib-Lese Dauer von VISA ist immer im gleichen Zeit-Bereich von ca. 16 ms laut NI Spy. Wobei gesagt sein muss, dass NI Spy die Verbindungsgeschwindigkeit um ca. Faktor 2 verlangsamt.
Und wie man bei TCP/IP sieht sind hier sehr starkte Schwankungen! Abgesehen davon, dass ich auf keinem Realtime System arbeite - kann es nicht sein, dass die Werte so sehr schwanken. IEEE 488 läuft mit 625k Baud - also Faktor 3 besser wie LAN - und man misst auch die schnellere Kommunikation zw. Client und Gerät. Und die Zeit ist auch Konstant.
Ich verstehe ja, dass bei LAN mehrere Verbindung nach aussen offen sein können - und mein Gerät wohl nicht der einzigste Client ist. Aber kann das so viel Zeit ausmachen? Ich werd mich mal mit einen Crosskabel draufhängen und dann mal Messen. Mal sehen ob ich da eine stabilere Verbindung messe.
MFG
TCP und dessen Header - rolfk - 22.07.2009 09:44
Andere Variante könnte sein das die TCP/IP Implementation in VISA irgendwie suboptimal ist.
Ausserdem schickst Du das alles ab als einzelne Pakete pro Wert? Dann vielleicht auch mal den Nagle Algorithmus ausschalten. Das geht bei VISA über ein Property TCP No Packet Delay (TCP NoDelay) das dann auf True gesetzt werden muss.
Trotzdem leuchtet mir nicht ein warum man alle x Userwerteänderungen innerhalb von 100ms an ein Gerät schicken sollte. Wenn das ein Einstellwert eines Regelkreises ist wird dieser Regelkreis durch die schnelle Anpassung dieses Stellwertes sicher nicht stabiler. Klingt irgendwie einfach minimal sinnlos für mich aber wahrscheinlich sogar dem Prozess abträglich. Da das ganze von einem Benützer kommt, kann kritisches Timing eh nicht der Grund sein denn ein Benützer hat niemals eine Genauigkeit von 100ms ganz zu schweigen von seiner Reaktionszeit.
Rolf Kalbermatter