LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I send ASCII Stream with TCP-Write?

I'm trying to send data from Labview server to client application. The data is string (concatenated from different input string with concatenate strings-node) and it should be send in form of ASCII stream (not binary form). Can I send ASCII stream via TCP-write node?
0 Kudos
Message 1 of 8
(6,113 Views)
Yes.

Go to the Example Finder search for tcp.
Look at the TCP Communicator - Active.vi
I think this should help you.
0 Kudos
Message 2 of 8
(6,083 Views)
Thank you for answering!

I'm not still sure that LV sends messages in ASCII text from. Are you sure, that there is no binary form conversion between those Active and passive vi's?

I'm thinking that TCP write converts ASCII to binary (before sending) and then TCP read converts it back to ASCII format in that another vi.
0 Kudos
Message 3 of 8
(6,066 Views)

@evila wrote:
Thank you for answering!

I'm not still sure that LV sends messages in ASCII text from. Are you sure, that there is no binary form conversion between those Active and passive vi's?

I'm thinking that TCP write converts ASCII to binary (before sending) and then TCP read converts it back to ASCII format in that another vi.




There is no difference between binary and ASCII as far as the stream itself in LabVIEW is concerned. In fact TCP/IP also makes no difference at all. It is always a stream of bytes, independant if there happen to be readable characters in there or simply some random or not so random binary data bytes.

The only difference you have in some higher level protocols such as FTP is about how to treat special characters such as carriage returns and line feeds. LabVIEW does nothing of this on its own, you specifically have to include any carraige return and/or line feed you want to send. One convinience option LabVIEW has is the mode parameter of the TCP Read function, which can be set to CR/LF and that means that LabVIEW will terminate the read as soon as either:

1) the requested amount of bytes have been read
2) the timeout has expired
3) a carriage return/line feed pair has been received

This mode allows to easily support line oriented protocols, as there are many of them built on TCP/IP.

But inherently an ASCI string is simply an array of bytes as well and therefore you can always transport ASCII strings through a binary stream but not vice versa.

If you want to send ASCII strings it is likely that you will also have to add the cr/lf characters to them and in LabVIEW you have to do this explicitedly, as LabVIEW will not do any implicite ASCII->binary conversion at all as you seem to think.

Rolf Kalbermatter

Message Edited by rolfk on 06-21-2005 06:10 AM

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 8
(6,061 Views)
Why does it matter how the TCP VIs work? Eventually everything is binary.
Is your client application written in another language?
Did you run into any problems?
If you are using another language and did run into problems, my guess is that you may need to reverse the bit order inside each byte to get the ASCII chars.

___________________
Try to take over the world!
0 Kudos
Message 5 of 8
(6,058 Views)
Yes, the client application is written in Envision/Igrip program with Graphic Simulation Language (GSL) (a programming language developed by DELMIA)

I'm reading information from USB joysticks with LV (server) and the data should be send to the client. I can establish a connection between server and client, and I can also send data from client to LV server, but I can't read data form LV with my client application. I'm using normal TCP/IP read write routines in LV.

Here is the LV server vi, maybe here is some problems with my vi.
0 Kudos
Message 6 of 8
(6,047 Views)

@evila wrote:
Yes, the client application is written in Envision/Igrip program with Graphic Simulation Language (GSL) (a programming language developed by DELMIA)

I'm reading information from USB joysticks with LV (server) and the data should be send to the client. I can establish a connection between server and client, and I can also send data from client to LV server, but I can't read data form LV with my client application. I'm using normal TCP/IP read write routines in LV.

Here is the LV server vi, maybe here is some problems with my vi.




Most probably your client is waiting for a carriage return and/or line feed before proceeding to decode the command so you will have to append that to the string before passing it to TCP Write. Just as mentioned in my earlier post.
Are you really sure the client expects a binary 32 bit integer first, telling it the number of bytes? Looks a little strange considering that everything else is completely in ASCII. If it really does expect a binary 32bit integer you will have to investigate if this is supposed to be in big endian or little endian. Chances are for applications developed on Intel x86 CPUs that they expect little endian, but LabVIEW and also most network applications do expect big endian instead. You can change the endianess by wiring the integer value through Swap Bytes and Swap Words from the Advanced palette, before typecasting it to a string.

Rolf Kalbermatter

Message Edited by rolfk on 06-21-2005 08:24 AM

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 7 of 8
(6,040 Views)

Thank you for helping me, the problem is now solved.

0 Kudos
Message 8 of 8
(5,995 Views)