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!
vielleicht kann mir hier jemadn helfen.
Möchte einen String über eine TCP Verbindung senden und Empfangen. Ziel soll der localhost mit der Portnummer 1234 sein.
Hiermit will ich Daten aus LabVIEW einem anderen Programm zur Verfügung stellen.
Empfangen funktioniert, jedoch macht das Senden Probleme. Der Aufbau ist der identsiche wie bei Empfangen, mit dem
Unterschied, dass TCP schreiben eingefügt wurde.
Beim Ausführen erfolgt Fehler 63.
Lesen und Scheiben sind in einer Sequenz hintereinander.
Füge beide Sequenzen mit der Fehlermeldung bei.
vielleicht kann mir hier jemadn helfen.
Möchte einen String über eine TCP Verbindung senden und Empfangen. Ziel soll der localhost mit der Portnummer 1234 sein.
Hiermit will ich Daten aus LabVIEW einem anderen Programm zur Verfügung stellen.
Empfangen funktioniert, jedoch macht das Senden Probleme. Der Aufbau ist der identsiche wie bei Empfangen, mit dem
Unterschied, dass TCP schreiben eingefügt wurde.
Beim Ausführen erfolgt Fehler 63.
Lesen und Scheiben sind in einer Sequenz hintereinander.
Füge beide Sequenzen mit der Fehlermeldung bei.
Gruß
Mev
Die Windowsfirewall oder eine andere Firewall hast Du ja hoffentlich schon überprüft, nicht das daher die Probleme kommen.
Hast Du testweise mal einen anderen Port als die 1234 versucht?
Mal sehen was noch an anderen Vorschlägen kommt.
Gruß,
Rob
PS: Sind die ganzen globalen Variablen echt notwendig?
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
' schrieb:Die Windowsfirewall oder eine andere Firewall hast Du ja hoffentlich schon überprüft, nicht das daher die Probleme kommen.
Hast Du testweise mal einen anderen Port als die 1234 versucht?
Mal sehen was noch an anderen Vorschlägen kommt.
Gruß,
Rob
PS: Sind die ganzen globalen Variablen echt notwendig?
Das "Grund-Problem" bei der TCP/IP Kommunikation ist: wieviele Daten will ich schicken und empfangen.
Dafür gibt es 3 Einstellungen: Standard, CRLF und immediately.
Es hat sich bewährt und da gibt es ein Beispiel im Example-Finder dazu (...) vorneweg die Länge des Strings (das sind immer genau 4 Byte) zu senden, diese 4 Byte zu empfangen und daraus wieder die Information zu gewinnen, wieviel Daten denn nun genau empfangen werden sollen.
Des weiteren musst du den Fehler 56 (timeout) abfangen, der periodisch auftritt, wenn du nichts sendest. Das ist dann in dem Fall weniger als "echter" Fehler zu interpretieren, sondern eher als "info", dass nix angekommen ist.
vielleicht kann mir hier jemadn helfen.
Möchte einen String über eine TCP Verbindung senden und Empfangen. Ziel soll der localhost mit der Portnummer 1234 sein.
Hiermit will ich Daten aus LabVIEW einem anderen Programm zur Verfügung stellen.
Empfangen funktioniert, jedoch macht das Senden Probleme. Der Aufbau ist der identsiche wie bei Empfangen, mit dem
Unterschied, dass TCP schreiben eingefügt wurde.
Beim Ausführen erfolgt Fehler 63.
Lesen und Scheiben sind in einer Sequenz hintereinander.
Füge beide Sequenzen mit der Fehlermeldung bei.
i2dx hat es schon angesprochen. Das wahrscheinlichste Problem ist: wie weiss der Empfänger dass jetzt alle Daten angekommen sind. Dazu gibt es grundsätzlich verschiedene Ansätze. Für Text basierte Protokolle wird dabei meist ein <CR><LF> Zeilenumbruch angefügt. Für binäre Protokolle wird meist im Datenstrom eine explizite Länge vorangestellt oder ein spezifischer Character reserviert als Ende-Zeichen.
Wenn Du die default Einstellung bei TCP Read verwendest beendet LabVIEW den Lesevorgang automatisch nach dem Lesen der entsprechenden Anzahl Bytes oder dem Timeout und liefert Dir die Daten zurück. Falls Du ein Text basiertes Protokoll hast wäre es aber wahrscheinlich sinnvoll den TCP Read Mode auf CRLF zu setzen, damit das Lesen nicht unnötig bis zum Ablauf des Timeouts hängen bleibt.
Beim Schreiben fügt LabVIEW nicht automatisch ein <CR><LF> ans Ende des Strings, Das musst Du schon explizit selber tun, ansonsten könnte man ja das TCP Write VI nicht benützen um auch binäre Protokolle zu implementieren. Ohne <CR><LF> wartet Dein Client aber wahrscheinlich ewig ohne das eigentlich bereits komplett empfangene Kommando je als gültig zu erkennen.
' schrieb:i2dx hat es schon angesprochen. Das wahrscheinlichste Problem ist: wie weiss der Empfänger dass jetzt alle Daten angekommen sind. Dazu gibt es grundsätzlich verschiedene Ansätze. Für Text basierte Protokolle wird dabei meist ein <CR><LF> Zeilenumbruch angefügt. Für binäre Protokolle wird meist im Datenstrom eine explizite Länge vorangestellt oder ein spezifischer Character reserviert als Ende-Zeichen.
Wenn Du die default Einstellung bei TCP Read verwendest beendet LabVIEW den Lesevorgang automatisch nach dem Lesen der entsprechenden Anzahl Bytes oder dem Timeout und liefert Dir die Daten zurück. Falls Du ein Text basiertes Protokoll hast wäre es aber wahrscheinlich sinnvoll den TCP Read Mode auf CRLF zu setzen, damit das Lesen nicht unnötig bis zum Ablauf des Timeouts hängen bleibt.
Beim Schreiben fügt LabVIEW nicht automatisch ein <CR><LF> ans Ende des Strings, Das musst Du schon explizit selber tun, ansonsten könnte man ja das TCP Write VI nicht benützen um auch binäre Protokolle zu implementieren. Ohne <CR><LF> wartet Dein Client aber wahrscheinlich ewig ohne das eigentlich bereits komplett empfangene Kommando je als gültig zu erkennen.
Rolf Kalbermatter
Hallo,
habe es probiert und komme immer noch zu keiner Lösung.
Habe eine TCP/IP Schnittstelle schon einmal in einem anderen VI benutzt. Es läuft zwar nicht, aber es kommen
auch keine Fehlermeldungen.
Ich habe alles aus diesem VI gelöscht und das Programm laufen lassen. Das gleiche Ergebnis.
Dann habe ich diese Schleife in ein neues VI kopiert und plötzlich generiert es Fehlermeldungn.
Ist es vielleicht möglich, dass mir jemand ein kleines VI zur Verfügung stellt, wo parallel was gelesen wird und wieder
ausgegeben (localhost).
' schrieb:Ist es vielleicht möglich, dass mir jemand ein kleines VI zur Verfügung stellt, wo parallel was gelesen wird und wieder ausgegeben (localhost).
Das ist nicht nötig. Gibt mehrere Beispiele die direkt mit LabVIEW mitkommen. Schau mal im Example Finder nach unter dem Suchbegriff TCP.
' schrieb:Das ist nicht nötig. Gibt mehrere Beispiele die direkt mit LabVIEW mitkommen. Schau mal im Example Finder nach unter dem Suchbegriff TCP.
Rolf Kalbermatter
Hallo,
mein Problem war, dass LabVIEW immer einen zuhörer Braucht, sonst kommt eine Fehlermeldung.
Habe mir Rat aus den LabVIEWbeispielen geholt.
Ich muss das VI, welches zuhört als erstes starten sonst funktioniert es nicht.
Ich wollte schreiben und im Folgeschritt lesen. Ist das überhaupt möglich? Denn wenn der Gegenüber nicht
auf hören bzw lesen geschaltet hat, wird doch sofort ein Fehler produziert.
Müssten sich beide nicht auf einander abstimmten?
mein Problem war, dass LabVIEW immer einen zuhörer Braucht, sonst kommt eine Fehlermeldung.
Habe mir Rat aus den LabVIEWbeispielen geholt.
Ich muss das VI, welches zuhört als erstes starten sonst funktioniert es nicht.
Ich wollte schreiben und im Folgeschritt lesen. Ist das überhaupt möglich? Denn wenn der Gegenüber nicht
auf hören bzw lesen geschaltet hat, wird doch sofort ein Fehler produziert.
Müssten sich beide nicht auf einander abstimmten?
TCP/IP Übertragung ist VERBINDUNGSORIENTIERT. Was bringt dir das Senden der Daten ins Leere?
Um die Daten einem anderen Programm zur Verfügung zu stellen machst du einen Server:
' schrieb:TCP/IP Übertragung ist VERBINDUNGSORIENTIERT. Was bringt dir das Senden der Daten ins Leere?
Um die Daten einem anderen Programm zur Verfügung zu stellen machst du einen Server:
[attachment=34295:Server.PNG]
eg
Hi,
habe das soweit hinbekommen. Nur, dass ich jetzt wieder ein anderes Problem habe. Ich empfange nur 1x!
Der Wert ändert sich nicht weiter, obwohl etwas anderes gesendet wird.
Hatte das gleiche Problem beim Senden. Habe die Verbindungserstellung ausserhalb des Programmes gesetzt und
damit das Problem behoben. Beim Empfangen gestaltet sich das leider anders.
Füge ein Bild meines Empfangvorgangs bei.
Wenn es geht, soll es ohne Listener programmiert werden
