From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

delay tcp open connection on RT target

Hi everyone,

 

Im having a problem with opening an tcp/ip connection to a RT pc. The setup I'm using consists of a windows pc (client) and a RT desktop pc (server) running ETS. At the client side I open a tcp connection, and the RT side listens for an incoming connection.

 

At first, my windows and RT pc were a part of the LAN at my work and everything worked fine. Now i took both pc's out of the LAN and connected them directly together with a cross over cable. I also gave both pc's a fixed ip address and the same subnet address. This worked fine up until a week ago. Now if i try to open a tcp connection, the RT pc gives the following message: "Waiting for real time target to respond, Stop waiting and disconnect".  In case you ignore the message, about  20 seconds later a connection established. Once the connection is made, the rest of the communication seems to be working fine.

 

I cant figure out why it takes so long to setup that connection, i also noticed that my Labview program on the RT pc freezes those 20 seconds or 19. 

Other post's regarding more or less this issue, suggested that it had something to do with the DNS server, but when i directly connect 2 pc's together, then the DNS server is out of the picture?

 

Greetz,

Ynse 

0 Kudos
Message 1 of 3
(3,001 Views)

Hi Ynse,

i think the message "Waiting ..." is normal, if you start your rt vi from the inside the project. Did you change something on your pc, what can cause these delay?

 

Mike

0 Kudos
Message 2 of 3
(2,984 Views)

Hi everyone,

 

The problem is solved (for now it seems to be working). On the server side i used the "TCP listen.vi" that is used in the LabVIEW examples, but this vi does a little more then just listen for an incoming connection, it also has an "internecine avoider vi". So i replaced the "TCP listen.vi" by an "create listener" and "wait for listener" block, after that the target didn't complain anymore about not responding. Maybe the "TCP listen.vi" has trouble with real time behaviour or the other way around? But anyways i can continue with my application now 🙂

 

Greetz, Ynse. 

Message 3 of 3
(2,943 Views)