Showing results for 
Search instead for 
Did you mean: 

Client application not receiving data from a TCP multi connection server (9068)


I developed a standalone application meant to be installed on a user's laptop for talking to my 9068 in order to receive basic system updates and, when available, job reports. Previously, I tested the client-server interaction on the same machine with success. Now that I've installed the application on another laptop, I can't seem to establish a good connection. What's worse, sometimes I do and sometimes I don't. In any case, I don't receive data. 


The server is a very lightly modified take on the TCP Multiple Connections example VI, where I transmit synchronous messages on timeout errors (56) and asynchronous messages upon user request. The server side is slightly modified to use eth1 exclusively (str ip vi, multiple outputs, array index 1) going to the net address of the TCP Create Listener VI. I am listening on port 1174. According to probes on the server, the clients are always added successfully and even written to successfully on timeout messages, but from a client standpoint, there are issues. The client generates an Error 63 upon attempting to connect:


Error 63 occurred at TCP Open Connection in

Possible reason(s):

LabVIEW: Serial port receive buffer overflow.
LabVIEW: The network connection was refused by the server.


I am certain the reason I don't get anything on a read request on the client side is because my connect ID is a result of an error out on the init (connection ID is '0'). I don't understand how a serial port buffer overflow applies to this situation. Also, I am able to ping eth1 of the RIO, so presumably my IP/subnet settings aren't too off. Just a stressful situation to be in with deadlines looming. Smiley Sad



0 Kudos
Message 1 of 9
Can you post the code? It is really hard to troubleshoot a picture.


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
0 Kudos
Message 2 of 9

Thank you for your interest. Let me know if I need to correct any dependency issues. There is some code I've omitted, such as the full scale UI that queues up the asynchronous requests that get sent to the server, but the main portion is there. Client application is executed in gui/ and server is rt_tcp_handler. 



0 Kudos
Message 3 of 9

hi dest2ko,


You said this worked on another machine, right? Were you able to connect and receive data on the other one?


What was different between that one and the one you are on now?  Is the code absolutely identical between the two?

0 Kudos
Message 4 of 9



The applications seems to work well when I run the server and client on the same machine and just use localhost input strings for the tcp session function blocks. I was able to execute both commands via that setup. The TCP handler is identical. I used that (maybe a bit redundant) queue FGV as way to easily get my queue reference anywhere in the application without serving up too much spaghetti. The only difference now is the reassignment of the NIC/net address for the server to listen on and that they are on different machines with different addresses within the same subnet. 




0 Kudos
Message 5 of 9

The error code you are getting doesn't necessarily  mean "LabVIEW: Serial port receive buffer overflow." It is most likely the second error message that applies here: "LabVIEW: The network connection was refused by the server." which could be something that comes from a network or firewall setting.


When you say that you only sometimes get the error, could that be becuase your listener is not running when you start the sender?  It's important for the listener to be started first with TCP/IP.


Also, do you have the same OS on all computers you've tested this on?  Different OS handle buffers differently.

0 Kudos
Message 6 of 9

I'm running WIndows 7 on both systems.


I have made sure the server is started first. Whenever I attempt to connect from the client, the server always recognizes it and generates a connection ID from the listener, but in the initialization on the client side, a '0' is always returned from the Open Connection VI, returning the error 63.


0 Kudos
Message 7 of 9

The current workaround has been just deploying a shared variable into the bundled application executable. It is working pretty well, but I'm really trying to avoid shared variables. I am curious about that working if the PSP utilizes similar underlying communication methods. This will also not be a very viable solution (IMO) when needing the ability for the client to select from multiple servers. 

0 Kudos
Message 8 of 9

I'm not really sure what is causing that issue. I would try to simplify the program as much as possible, and establish connection to the server with the most basic VI possible to make it easier to troubleshoot.


It would be ideal to try to get an example to work, and then work from there to make changes little by little, finding out what is causing the issue.  If you can't get a TCP example to work, the issue is almost certainly in the network settings.


In the meantime, here are some other people who have had the same issue. There is some good info here:




0 Kudos
Message 9 of 9