INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

TCP und dessen Header



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

20.07.2009, 16:18
Beitrag #1

Ragdar Abwesend
LVF-Grünschnabel
*


Beiträge: 47
Registriert seit: Mar 2009

8.2
2008
kA

83022
Deutschland
TCP und dessen Header
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
20.07.2009, 16:27
Beitrag #2

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
TCP und dessen Header
Ich würde entweder die Inkrementierung des Controls vergrössern oder gar beim Mouse Up Event die Daten erst abschicken.

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
20.07.2009, 22:21 (Dieser Beitrag wurde zuletzt bearbeitet: 20.07.2009 22:21 von schrotti.)
Beitrag #3

schrotti Offline
LVF-Freak
****


Beiträge: 842
Registriert seit: Feb 2008

2009 - 2011
2006
kA

70180
Deutschland
TCP und dessen Header
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.

Gruß Julius
Empfehlungen: expressionflow, LavaG , mooregoodideas, OpenG, JKI Blog
Tipp
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.07.2009, 06:29 (Dieser Beitrag wurde zuletzt bearbeitet: 21.07.2009 06:30 von Ragdar.)
Beitrag #4

Ragdar Abwesend
LVF-Grünschnabel
*


Beiträge: 47
Registriert seit: Mar 2009

8.2
2008
kA

83022
Deutschland
TCP und dessen Header
' 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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.07.2009, 10:26
Beitrag #5

MichaDu
Unregistered


 







TCP und dessen Header
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.
Diese Nachricht in einer Antwort zitieren to top
21.07.2009, 11:03
Beitrag #6

RoLe Offline
LVF-Guru
*****


Beiträge: 1.236
Registriert seit: Jul 2007

-
1997
en

0
Schweiz
TCP und dessen Header
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.

.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
22.07.2009, 06:23
Beitrag #7

Ragdar Abwesend
LVF-Grünschnabel
*


Beiträge: 47
Registriert seit: Mar 2009

8.2
2008
kA

83022
Deutschland
TCP und dessen Header
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...


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.07.2009, 07:48 (Dieser Beitrag wurde zuletzt bearbeitet: 22.07.2009 07:49 von rolfk.)
Beitrag #8

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
TCP und dessen Header
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

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.07.2009, 08:47
Beitrag #9

Ragdar Abwesend
LVF-Grünschnabel
*


Beiträge: 47
Registriert seit: Mar 2009

8.2
2008
kA

83022
Deutschland
TCP und dessen Header
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.07.2009, 09:44 (Dieser Beitrag wurde zuletzt bearbeitet: 22.07.2009 09:44 von rolfk.)
Beitrag #10

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
TCP und dessen Header
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

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Gehe zu: