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!
Ich habe ein VI mit mehreren SubVIs, welches per TCP/IP Messdaten von mehreren Mikrocontroller abfragt. Hierfür wird zu jedem Mikrocontroller eine Verbindung aufgebaut, Write/ Read und wieder geschlossen. Auch wenn das nicht optimal ist, klappt das sehr gut.
Des Weiteren kann der Anwender per UDP die IP-Adresse der Controller während der Laufzeit ändern. Werden den Controllern IP-Adressen zugewiesen, welche während der Laufzeit des VIs frei waren, läuft das VI fehlerfrei weiter. Tausche ich die IPs von zwei Mikrocontrollern untereinander aus, so kann zu beiden keine TCP/IP Verbindung aufgebaut werden (siehe Bild). Über UDP sind die beiden Controller weiterhin erreichbar und zeigen auch die geänderten IP-Adressen an. Starte ich das VI neu, so werden die Controller auch mit der geänderten IP-Adresse wieder angezeigt.
Ich habe trotz der Funktion "TCP: Verbindung schließen" das Gefühl, dass die Verbindung nicht komplett geschlossen wird. Im Anhang ist das VI (Init UDP+TCP), welches nach der Änderung der IP-Adresse die Geräte im Netzwerk ermittelt und über TCP Gerätedaten abfragt. Vielleicht hat jemand ne Idee, wie ich mein Problem beseitigen kann. Die IP-Adresse im Bild ist korrekt.
zunächst einmal habe ich keine Ahnung, mit TCP IP habe ich bisher sehr wenig beschäftigt.
Außerdem glaube ich, dass mein Kommentar nicht mal direkt was mit deinem Problem zu tun hat
Trotzdem bin ich an deinem beigefügten Screenshot an etwas hängengeblieben, kann sein, dass Folgendes völlig falsch ist, also ignorier' mich einfach, wenn dich das nicht weiterbringt:
Du scheinst hier an den remote port 60000 anzuschließen und an den Timeout lediglich 500.
Mal abgesehen davon, dass ich aus der Anleitung nicht wirklich schlauer werde, wozu der remote port genau da ist, sieht das für mich erstmal wie eine versehentliche Falschverdrahtung aus. So hat das jeweilige Gerät 500ms zum Antworten, was - je nach Betriebsamkeit - doch etwas knapp gewählt ist und im beobachteten Timeout resultieren könnte.
Außerdem gebe ich hier noch unmotiviert ein paar weitere Verbesserungsvorschläge:
1) SubVIs sind eine tolle Sache (wenn man sie einsetzt)
2) Datenfluss auch (raus mit der Sequenzstruktur)
3) Timeout-Anschlüsse bei KommunikationsVIs reichen in der Regel aus, um Timing in den Griff zu bekommen - zusätzliche Delay-VIs, so nett sie auch um den error-Cluster gemalt werden, sind da überflüssig
Viel Erfolg bei der Lösung deines Problems.
Grüße,
Kasi
If you're havin' serial communication problems I feel bad for you, son, I got 99 problems but a baud ain't one! (except if using USB2serial converters, then I experience serialous problems)
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
RE: Verbindungsprobleme TCP / IP
Als "Connection ID" 0 ist auch sehr seltsam. Ich habe da immer eine mehrstellige Zahl.
Gruß Markus
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
RE: Verbindungsprobleme TCP / IP
Stimmt. Da war doch was.
Zeit für Mittag.
Gruß Markus
(05.02.2014 12:53 )jg schrieb: Es kommt ja auch gleichzeitig ein Fehler raus! ID 0 = "No connection".
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
05.02.2014, 14:35 (Dieser Beitrag wurde zuletzt bearbeitet: 05.02.2014 14:45 von TiCy.)
Ich hoffe Markus und Jens konnten die Unklarheiten untereinander beseitigen und die Mittagspause war angenehm .
Kasi ich stimme Dir voll zu das SubVIs das Programm deutlich übersichtlicher machen würden und die flache Sequenz überflüssig ist. Die Sequenzen soll das VI nur übersichtlicher machen, damit der UDP-Teil und der TCP-Teil getrennt betrachtet werden können. Die Wartezeiten von 500ms reichen im Normalfall bei mir völlig aus. Die Delay-VIs müssen nicht sein, aber schaden auch nicht ;-)
Die Ursache meines Problems liegt darin, dass die TCP-Verbindung nach der Funktion " TCP: Verbindung schließen" nicht komplett geschlossen wird, sondern in den Status "Wartend/ Wait_time" geht. Über den Konsolenbefehl "netstat" sieht man das gut.
Ich suche aktuell nach einer Lösung die Verbindung sofort zu schließen, um die Wartezeit von 60 Sekunden zu umgehen. Erst nach dieser Zeit wird die TCP-Verbindung im Status "Wait_time" automatisch beendet.
du versuchst in der Schleife N Verbindungen (jeweils als Client) auf die im Array deklarierten IPs allesamt mit dem Port 60000 und einem TO von 500ms zu erstellen. Mal abgesehen davon, dass mir 0,5s unter allen Umständen auch etwas knapp vorkommen, weiß ich nicht, ob es wirklich in allen Verbindungen der Port 60000 sein soll.
Ich arbeite permanent mit TCP und öffne / schließe meine Verbindungen auch mit den von dir verwendeten Funktionen. Dass die Funktion Verbindung schließen ihre Aufgabe nicht ernst nimmt kommt mir zudem auch recht spooky vor.
(05.02.2014 22:04 )Trinitatis schrieb: du versuchst in der Schleife N Verbindungen (jeweils als Client) auf die im Array deklarierten IPs allesamt mit dem Port 60000
Na und? Das ist der Port am Ziel (also an den unterschiedlichen Zielen). Wenn das nicht geht, dann geht kein Browser. Der öffnet TCP IP auf Ports 80 und 443.
Anderes Bsp: x Modbus-Slaves im Netz, da öffnest du immer Port 502.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
(05.02.2014 22:04 )Trinitatis schrieb: du versuchst in der Schleife N Verbindungen (jeweils als Client) auf die im Array deklarierten IPs allesamt mit dem Port 60000
Na und? Das ist der Port am Ziel (also an den unterschiedlichen Zielen). Wenn das nicht geht, dann geht kein Browser.
Ich habe nicht behauptet, dass das nicht gehen kann!
Ich habe nur den aktuellen Status beschrieben - wenn das alles so korrekt ist, dann is ja gut. Aber irgendwo muss ja der Fehler liegen, sonst würd´s wohl funzen.
Manchmal ist nur das, was LV-Anfänger glauben, programmiert zu haben, nicht das, was sie letztlich programmiert haben (z.B. wenn hier TO und Port vertauscht worden wären)
Gruß, Marko
06.02.2014, 08:43 (Dieser Beitrag wurde zuletzt bearbeitet: 06.02.2014 08:53 von TiCy.)
Eine alternative zum Port 60000 ist nicht möglich, weil nur auf diesen Port ich den Mirkocontroller ansprechen kann. Das VI/SubVI (siehe Bild 30.01.) funktioniert in 99% der Durchläufe fehlerfrei. Der einzigste Fall wo dies nicht geht, ist wenn ich vorher per UDP die IP-Adressen untereinander durchgetauscht habe und eine Wartezeit von 60 Sekunden nicht eingehalten wurde.
Mein Problem liegt darin, dass die TCP-Verbindung nach der Funktion " TCP: Verbindung schließen" nicht komplett geschlossen wird.
Wer das gerne testen will, einfach per LabVIEW TCP-Verbindung aufbauen und schließen. Dann innerhalb von max. 60 Sekunden auf Ausführen / cmd / netstat gehen. Ein Beispiel von mir findet Ihr im Anhang.
