TCP mit asynchronem VI - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +---- Forum: Datenkommunikation (/Forum-Datenkommunikation) +---- Thema: TCP mit asynchronem VI (/Thread-TCP-mit-asynchronem-VI) Seiten: 1 2 |
RE: TCP mit asynchronem VI - jg - 24.06.2019 15:08 Ich hatte mir das auch angeschaut, interessant finde ich, dass dein Aufbau ohne (oder nur minimaler) Wartezeit nach der Queue-Abfrage funktioniert, nur bei längerer Wait funktioniert dann dein Konstrukt nicht. Spekulation meinerseits: Auf Grund des dynamischen Aufruf des Sub-VI wird das irgendwann komplett aus dem Speicher entfernt (im Gegensatz zu einem normalen Sub-VI Aufruf), und das reisst die TCP/IP-Verbindung mit ins Nirvana. Hast du einen aktuell gültigen SSP-Vertrag? Dann würde ich das mal NI vorlegen! Gruß, Jens RE: TCP mit asynchronem VI - 83Daniel - 24.06.2019 15:45 Vielen Dank, ja, habe einen SSP werde ich dann dort mal anfragen und ggf. Antwort hier posten. RE: TCP mit asynchronem VI - rolfk - 26.06.2019 20:59 (18.06.2019 08:19 )83Daniel schrieb: Ich hab da ein Problem mit dem Starten einer TCP Verbindung wenn ich sie in einem asynchronen VI starte. Du hast hier noch ein Problem. TCP Refnums sind LabVIEW Refnums und die Unterliegen einer automatischen Aufräumung in LabVIEW sobald das ToplevelVI in dem die Refnum erzeugt wurde beendet wird. Ein VI das als asynchrones VI aufgerufen wird, gilt als ToplevelVI da es kein Diagram gibt in dem es als subVI aufgerufen wird. Deine Idee um das Öffnen der TCP Verbindung in einem asynchronen VI zu machen, das die Referenz dann in eine Queue schiebt und sich danach beendet funktioniert also nicht. Und es gibt KEINE Möglichkeit um LabVIEW zu sagen dass es die Referenz nicht automatisch aufräumen soll. Und die Refnum ist nicht NULL aber eben doch abgeschlossen, wie wenn Du ein TCP Close darauf ausgeführt hättest, und daher ungültig. Mögliche Lösungen: 1) Öffnen der Verbindung nicht asynchron machen sondern innerhalb des Codes an dem jetzt Du Dein asynchrones VI startest. 2) Nicht nur die Verbindung in Deinem asynchronen VI machen sondern auch die ganze Datenkommunikation mit dem Server. Dein asynchrones VI ist dann also ein selbständiger Thread der solange aktiv bleibt wie die Verbindung mit dem Server instand bleibt. Statt die Refnum durch eine Queue an Dein Programm durchzugeben sollte Dein Connectionhandler stattdessen selber eine CommandQueue verwenden mit der Du Kommandos schicken kannst um etwas zum Server zu schicken oder zu lesen, aber auch ein Quit event, wenn der Handler sich beenden soll, und eine ResponseQueue mit dem Dein Handler Daten an Deine Applikation liefern kann. Diese Möglichkeit scheint Dir vielleicht am Anfang komplizierter aber ist eigentlich logischer, da alle Kommunikation in Deinem Handler zusammengefasst ist. Und wenn Du diesen Handler als Clone konfigurierst kannst Du ohne extra Mühe auch mehere solcher Handler nacheinander zu verschiedenen Servern starten und parallel laufen lassen. RE: TCP mit asynchronem VI - jg - 26.06.2019 21:05 (24.06.2019 15:08 )jg schrieb: Spekulation meinerseits: Auf Grund des dynamischen Aufruf des Sub-VI wird das irgendwann komplett aus dem Speicher entfernt (im Gegensatz zu einem normalen Sub-VI Aufruf), und das reisst die TCP/IP-Verbindung mit ins Nirvana. Hast du einen aktuell gültigen SSP-Vertrag? Dann würde ich das mal NI vorlegen! (26.06.2019 20:59 )rolfk schrieb: Du hast hier noch ein Problem. TCP Refnums sind LabVIEW Refnums und die Unterliegen einer automatischen Aufräumung in LabVIEW sobald das ToplevelVI in dem die Refnum erzeugt wurde beendet wird. Ein VI das als asynchronoes VI aufgerufen wird, gilt als ToplevelVI da es kein Diagram gibt in dem es als subVI aufgerufen wird. Deine Idee um das Öffnen der TCP Verbindung in eine asynchronen VI zu machen dass die Referenz dann in eine Queue schibt und sich danach beendet funktioniert also nicht. Und es gibt KEINE Möglichkeit um LabVIEW zu sagen dass es die Referenz nicht automatisch aufräumen soll. Da habe ich also richtig spekuliert. Vielen Dank an den LabVIEW- Rolf!!! Gruß, Jens RE: TCP mit asynchronem VI - 83Daniel - 27.06.2019 06:42 Danke, für der Erklärung! Ich erledige diesen Programmteil jetzt auch mit dem Actor Framework. Damit sind alle meine Randbedigungen erfüllt. |