LabVIEW
Interface between LabVIEW and C#
Solved!
This is about as simple as it gets. Even if I would write a simple example it wouldn't get much simpler than this.
I don't see anything glaringly wrong in this code, but in general I think the determination of the local address is somewhat wonky. It will find the IP address of the last ethernet interface.
Have you checked that this localIP address is a valid one, and which? Assuming you try to run the client and server on the same computer, can you try with the local loopback address 127.0.0.1 instead?
@danil33 wrote:
Hi,
I did a simple socket programing example in C# for receiving datas send from labview.It is attached below.It is showing that the connection is established but after clicking the 'send' button in labview no data is received.please check the VI.Is there anything to change in the labview code??Is the C# code incapable of receiving datas coming in that form?
Can you be more specific as to what doesn't work? Which messages do you see on your client application and which not? Do you see the "Message from Client$" message in LabVIEW? Does it hang, not show the data you expexct or what else? Where does it hang if it does?
I'm not intimately friends with .Net programming in general and don't know all the details about the System.Net.Sockets.TcpClient() class but it could as well be that serverStream.Write() or serverStream.Flush() do block if the data is not properly read on the remote side.
Well, read on MSDN about the TCPClient Stream implementation.
First thing to check would be how much bytes you are requesting from Read(). It could be 0 bytes, since the data has not arrived yet. And a read of 0 bytes likely will return immediately with exactly 0 bytes so there is nothing wrong with the code as it executes.
Instead to mimic the protocol you implemented in LabVIEW, you should always request 4 bytes first. stream.Read() is guaranteed to block until it receives the data the caller requested. Now you do have 4 bytes creating a 32 Bit integer value so you will have to convert those 4 bytes into an integer but be aware that LabVIEW flattened data is always send in Big Endian form, so you need to byte swap the data in this process. With this number you can now do a second Read() to receive the actual data.
Also watch out when printing the received data out. This is binary data that can contain NULL bytes and System.Text.Encoding.ASCII.GetString() considers a NULL byte to be a terminating indicator, and I'm sure your 4 bytes length indicator contains leading 0 bytes, unless you manage to send data that is more than 16MB in one go.
BTW: it is a rather bad form to send binary files on fora. Write the C# code in a simple ASCII text file instead and give it a txt ending if you can't attach it otherwise, but don't copy and paste everything into a Word document. For one, not everybody has word installed, and two Word has had macro code vulnerabilities in the past, so some people refuse to open Word documents from unknown sources.
Ha danil,
"Now after running both the server and client I can see some junk values"
Maybe because you already send "junk" from your server VI? Just look at your "data string" indicator, after setting it back to "normal display"...
Sometimes it really helps to use some probes for debugging. You would have seen those junk on your string wire connecting "flatten" and "TCP write"!
Sigh!
double is also a binary value and not a string, so just as much prone to endianess interpretation and embedded NULL bytes in the binary stream. As such the same as with the previous example applies as well. Als the junk data you see is the binary data. System.Text.Encoding.ASCII.GetString() simply tries to interpret that binary data as string and gets to this. It has no way to know that the binary data are in fact double values.
To start with try to send the data as string, not as flattened binary byte stream, that at least avoids any trouble in endianess interpretation as well as embedded NULL bytes, that System.Text.Encoding.ASCII.GetString() is bound to stumble over.
Also it would be a good idea to try to read in the LabVIEW example the string you send to server, preferably before you enter the loop and using the CRLF mode, and appending a proper \r\n sequence to the string in your C# example.
