LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

send command via tcp

Hello, I want to send a command and receive a respond via tcp but i'm a new user and

I don't now where to start! How we do the connection? Thank you for your futur help Smiley Happy

 

You can see my project but the block diagramm is not connected (all must be connect via tcp)

0 Kudos
Message 1 of 14
(5,629 Views)

Have you looked at the TCP examples that ship with LabVIEW?  What is the device with which you're communicating?  Do you know what commands to send, and what format the response will be?  You should not do it the way you've set it up in your VI - you do not want to execute several writes simultaneously followed by several simultaneous reads, because there's no guarantee that the reads and writes will match.  Instead, you should chain them together - do one write, then one read, then the next write, the next read, etc.  Also you should probably open the connection only once, outside the while loop.

0 Kudos
Message 2 of 14
(5,619 Views)

 

I want to communicate with a TS-7500  (embedded Arm with linux dedian on it). I do my own program on C++ and now i can send request for the temperature , set relay (on , off), see the relay state via tcp/ip. When i use telnet everything works but i got the do all with the labview. The command look like @#IP_address#commande@CR.... if it's done i should receive a respond similar like the command. I have to receive and send continually

 

For more details

@ = data header (start receive the command)

#   = byte to split argument

@ = data header (end receive)

cr  = byte to process the command

0 Kudos
Message 3 of 14
(5,615 Views)

I suggest you start with a simple VI that sends a single command and reads a single response, once.  No while loop, no complications.  Just a TCP Open, a TCP Write, a TCP Read, and a TCP Close, all chained together.  Make sure you put an error indicator at the end so you can see if an error occurs.  If you can't get that much working, upload that VI showing what you tried.  Once you have that working, it should be easy to expand to read several data points continuously.

 

Why would you include the IP address in the command header?

0 Kudos
Message 4 of 14
(5,609 Views)

The Internet Toolkit has VIs for Telnet (the link is for the Windows version, but there's a version for Mac and Linux as well). Of course, you could just write them yourself using the TCP/IP VIs, and it's not that hard, but depending on what you're doing this for, it might be cheaper just to buy the Toolkit.

0 Kudos
Message 5 of 14
(5,602 Views)

I'll concur that the internet tool kit has some slick easy to use vi's great for interacting with a TCP/IP UART.  About the only feature it lacks is a buffered read but, if you need one of those to talk to an embedded application you wrote and maintain,....well, I won't say it,  But you would deserve the criticism.


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 14
(5,599 Views)

@Jeff Bohrer wrote:

I'll concur that the internet tool kit has some slick easy to use vi's great for interacting with a TCP/IP UART.  About the only feature it lacks is a buffered read but, if you need one of those to talk to an embedded application you wrote and maintain,....well, I won't say it,  But you would deserve the criticism.


Veering slightly off-topic here... I'm not quite sure what you mean by a TCP/IP UART, but if you mean a device that acts like a serial port over TCP/IP, why wouldn't you just use the VISA functions for this?  You can create a VISA resource that communicates over TCP and is interchangeable with a serial resource.

0 Kudos
Message 7 of 14
(5,596 Views)

I mean like a tty socket into an embeded processor (command line shell).  the internet TK aleardy has a script engine, and some low level features to maintain simultaineous sockets to several ports on the same host (think of several PuTTY sessions at one time).  Unfortunately it does not use VISA but takes a more lightweight approach to TCP/IP.  As Saverio said you COULD write them yourself using existing APIs (even VISA) but my clients pay by the hour and the TK is allready packaged with Developer Suite.


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 14
(5,583 Views)

@Jeff Bohrer wrote:

I mean like a tty socket into an embeded processor (command line shell).  the internet TK aleardy has a script engine, and some low level features to maintain simultaineous sockets to several ports on the same host (think of several PuTTY sessions at one time).  Unfortunately it does not use VISA but takes a more lightweight approach to TCP/IP.  As Saverio said you COULD write them yourself using existing APIs (even VISA) but my clients pay by the hour and the TK is allready packaged with Developer Suite.


Looks like a heavier-weight approach to me, they're wrappers around the native TCP functions... although the scripting is neat, I didn't know about that.  For the original poster's needs, the telnet VIs look like they'd be the same complexity as the built-in TCP functions (the functions mirror each other exactly, with the exception of "Play Script").

0 Kudos
Message 9 of 14
(5,569 Views)

@nathand wrote:

@Jeff Bohrer wrote:

I mean like a tty socket into an embeded processor (command line shell).  the internet TK aleardy has a script engine, and some low level features to maintain simultaineous sockets to several ports on the same host (think of several PuTTY sessions at one time).  Unfortunately it does not use VISA but takes a more lightweight approach to TCP/IP.  As Saverio said you COULD write them yourself using existing APIs (even VISA) but my clients pay by the hour and the TK is allready packaged with Developer Suite.


Looks like a heavier-weight approach to me, they're wrappers around the native TCP functions... although the scripting is neat, I didn't know about that.  For the original poster's needs, the telnet VIs look like they'd be the same complexity as the built-in TCP functions (the functions mirror each other exactly, with the exception of "Play Script").


Closely, Read modes available change somewhat For instance you lose "buffered read" with the I-TK and that is kinda nice for clients with a message size parameter in a message header and no EOM charater type of format (Ancient practice but still used).

 

And it is light-weight compared to VISASmiley Wink 


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 14
(5,565 Views)