LabVIEW
Opening and closing TCP/IP connection in each iteration
Unlike e.g. UDP, TCP is connection based (both are part of TCP/IP, so you need to be more precise in the problem description). Establishing a TCP connection between two end points required a mutual exchange of packets (three way handshake, look it up (SYN, SYNACK, ACK) as well as several packets to tear down the connection. This is a lot of overhead and if the connection is not perfect (e.g. a few % packet loss), you can get significant stalls because of the various timeouts for retransmission requests and such. In your case, the payload is only a few bytes so most of the trasferred data is connection management. (Note that your IP address is not from a designated private adress range, so I assume that the connection involves quite a few public hops and is not local.)
The correct way is to open the connection once but add special code to reestablish the connection whenever the connection is lost. Trivial to do.
In any case, just looking at the code picture, I see a lot of beginner mistakes and other weird stuff, so I would also recommend to streamline the code overall. Here are some points:
- The squence structure serves no purpose. Execution order is already fully determined by dataflow alone.
- Why in the world would you branch the blue wire inside the sequence and index one element inside and one outside? That makes no sense! Index array is resizeable and you don't even need to wire the indices.
- "insert into array" is the wrong function to prepend some elements to an existing array and building an array that always has the same size. In fact you should initialize an array of four elements and replace two, keeping the operations in place or simply use "build array" with four inputs (recommended).
- The elapsed time express VI is not the most efficient way to determine loop rate and why are you wiring a large seemingly random constant to the time input? Makes no sense!
- Some of your error wires are missing. It makes no sense to send data if the connection cannot be established, for example.
You need to be careful with terminology. "real time" has nothing to do with speed. Who wrote the server program? If you can change it, you could buffer data and send accumulated data with timestamps. You could even use UDP if performance is more important than the occasional missing point.
@iman_h wrote:The data should be sent first so I placed the flat sequence in the while loop.
Dataflow dictates that reading cannot start until writing has completed because there is a data dependency (error wire and connection reference). The sequence structure does not add antything extra except for cluttering the diagram.
@iman_h wrote:Hi dear altenbach,
I changed the program to avoid continious connect and disconnect. I attached a snippet. This program does not work. After reading a byte, the inner while loop iterates but it seems that the connection becomes unavailable and error code 66 occures. (The peer closed the connection.) So the inner loop halts and a new connection is made.
I used one of the NI's whitepapers: "Basic TCP/IP communication in LabVIEW".
Thanks.
Why all the error indicators? Troubleshooting?
And that's not a snippet. It's a picture. Just like this isn't a code snippet.
LabVIEW snippets are png files with metadata that allows the picture to insert code into a block diagram when it is dropped on one. You create one by selecting code on your block diagram and selecting "Create VI Snippet from Selection" from the "Edit" menu.
Look into state machines. You only need one while loop.
Currently, your program cannot be stopped if there is no error. You can also wire the error directly to the stop terminal, no need to unbundle. Instead of "not"-ing the status, just change the stop condition to "stop if true".
