Labview GUI using TCP/IP Connections - Beginner

[d_ly28]

Hi All,

I hope everyone is doing well! I am new to LabVIEW, just downloaded this software the other night. Here's my issue: I am currently building a TestGUI to try implementing a basic read/write program. I already have a server that the client will be able to connect to.

So, my GUI should be able to connect to the GUI(which it can) and send commands using the send button that is on my VI. So for instance, if I was to send a command "read" to my server, the server will return a string with the message "read 0x blah blah". However, whenever I am using the "read" command, only "read" is coming back. I feel like this error is due to the bytes written/read in from both of the tcp write/read.

Attached below is my VI, if you could help that would be awesome. Also, is there a button that just resets it self to off? Like in this case, I have the send, but whenever I click it during run-time, it deflates and then I have to click it again, in which will cause the program to do some funky stuff.

I apologize if this issue is simple, I've been trying to find documentation, but I can't find any or I'm actually just terrible at researching.

Any help will do! Thank you everyone!!

- Derek

[Bob_Schor]

Boolean controls have six "Mechanical Actions" that you can select.  Somewhere there's a discussion of them, but they include "True while pushed" (i.e. a doorbell) and two that are "latched", which means they "stick" until you read them, then they return to their default value.  With this set of six actions, you can do some interesting things ...  Experiment, and read the Help documents (and look at the Examples).

Bob Schor

[RavensFan]

Don't put two different event structures in your VI!.  Unless you really know what you are doing, you are going to lock your VI up cold

Why?  You have both of them set to lock the front panel until the event completes.  If the user presses the buttons in the wrong order, you'll lock up the VI.  Just use one event structure with multiple cases.

As Bob pointed out, you are using the wrong mechanical action.  For the send button, you should be using Latch When Pressed and it should be in its event case.

For the Connect button, use Switch when released.  You should also use it in a way so that when it is true, it makes the connection, when it is false, it will close the connection.  Right now it keeps opening a connection whether you are switching it ON or switching it OFF.

[d_ly28]

Hi Bob and RavensFan,

Thank you so much for your input! I apologize for the late reply. 

Ahh I see, that's what I was confused about because the button would crash the connection after I had tried to turn it off. Hmm okay, so to use the events, it would just be two separate events or in this case one event will different cases to handle different scenarios? One for connection and one for reading/writing the data?

Thanks for both of your help! I will try implementing this new button today and let y'alls know how it goes!

Thanks,

Derek

[paul.r]

Two events, one event structure. I would put your IP Address String and Port number inside the 'connect' case of the event structure. As they are currently wired, they will be read once at the start of the program, so you are unable to change them without stopping and restarting the program. Put your TCP connection reference on a shift register, and pass it through the event case structure - you may want to add a check to ensure it is a valid connection reference before attempting to write/read from the connection. 

Also, add an event case for the stop button - otherwise it will not be read until another event is fired. As a general rule of thumb, if you are using an event structure inside a while loop, all actions that are occurring inside the loop should take place in one of the event cases. Similarly, the control that triggers an event should usually go inside that particular case of the event structure. 

[d_ly28]

Hi Paul,

Awesome! Thank you for your reply. I actually got it to work so now it's flowing nicely and not crashing like before!

Okay, so I have another question that is bugging me. I am using the TCP/IP read function after I send instructions to the server. Now, the server is responding, but with each commands, there are going to be different amount of bytes that I need to read. I've been googling/going through documentation and forums to find an bytesAvailable function or something from LabVIEW. Does this exist? Because as of right now, whenever I am using read (standard mode), I am indicating that I want x bytes, but with the next command, then I want z bytes. The program crashes and gives me error 56 because the two byte sizes are different.

Thanks everyone for your help!

Derek

[crossrulz]

You need to add the size information into your message packets.  A common way to do this is to get the size of the data using String Length and then use Flatten Into String followed by a Concatenate String to prepend the length to your data.  You can then send the string with the TCP Write.  On the read side, you read 4 bytes (length of an I32), use Unflatten From String to convert to an I32 and then use that to tell the TCP Read how many bytes to read.

If you want a good example, go to Help->Find Example.  From there, do a search for TCP/IP and you will see a Simple TCP.proj.  It uses the Type Cast instead of the Unflatten From String, but it works the same here.

[Bob_Schor]

If you look at the Help documentation for TCP Write, it describes three methods you can use to write variable-length "messages" that need to be accurately read by the receiver (I know that you are trying to read, not write, but follow along with me ...)

• Write a Header that says "N bytes to follow" -- typically, the header is an I32 that takes 4 bytes to send.
• Write a Fixed-size Block, always the same size.
• Write Ascii Text, terminating the Text with <CR><LF>

Now look at the Help for TCP Read.  There are four Modes for reading -- three are of the "read specific # of bytes", with different behaviors having to do with the Read Timeout, and the fourth is "Read until CRLF".  If you are doing the "Header with N bytes to follow" method, you read 4 bytes, decode it, then read the "real data" that follows.

Bob "You Pays Your Money, You Takes Your Choice" Schor

[d_ly28]

Hi Bob and Crossrulz,

It works!!! I implemented both of your methods for having the initial header and it is working perfectly.

So, I have just one more question for this...how come LabVIEW never built a function for this? It seems as this has been around for some time and people just adapted to it by using this method. 

Thanks again for everything guys!

Derek

[Bob_Schor]

The "P"s in TCP/IP stand for "Protocol".  Communication over the Internet is controlled by a "Protocol-Stack", either the 7-layer OSI stack or the 4-layer TCP/IP Stack (of which TCP is Layer 3, and IP is Layer 2).

To actually communicate over these wires, we need the upper layers that define the structure of the Data.  This can be almost anything that the User desires.  Think, for example, about saving data in Files -- you can write Ascii Text, define a DataBase (and there are quite a few, all with different Formats), use some of NI's Data Formats (such as TDMS, or save the data as "binary", meaning as the bits are stored in the PC's memory.

NI is also giving you this flexibility.  Do you want to transmit only Text (which can be "inefficient", but is certainly "human-readable"?  Then use the CRLF method.  Transmitting in other ways?  Use one of the "Size-header" formats.

Note that NI also has TCP/IP protocols, such as Network Streams, that (probably) do just that.  You set up the Communication link, then simply "shove the data down the pipe" and LabVIEW figures out how to put it together at the receiving end.

If you want to do "low-level" TCP/IP functions yourself, then you have to accept that "it's up to you how you package and unpackage your data for transmission".

Bob Schor