Error 64: Network connection is not yet established?

[JoeSecurity]

Hi. I've created a RTOS to be run on a PXI8175 controller (host_*.VI, TCL_*.VI, and NPL_*.VI) connected via ethernet. My target is the controller and I open the Host_*.VI. The loop VI's are downloaded but when the program tries to run, I get Error 64: Network connection is not yet established. Any ideas?

[Bob_Preis]

NPL_*.vi needs to run before Host_*.vi can connect to it. NPL creates a TCP listener.

If this doesn't solve the problem, try running one of the simple TCP server/client examples between your two computers.

[Bob_Preis]

...one more thing

It also occurred to me that your TCL_*.vi might not have sleep in the main loop. If this is the case, your TCP listener, which runs in a normal priority thread, cannot answer attempted TCP connections from other hosts.

[JoeSecurity]

In the main Control Loop I'm using the Wait function to create a delay of 20 ms. Perhaps this is not enough?

[Bob_Preis]

That might be the problem, but to know for sure, we must determine the inherent execution overhead in your time-critical loop.

Drop a pair of tick counts - one right at the beginning of the TCL loop and one right before the TCL goes to sleep. If the difference is close to 20ms we have our answer (assuming the TCL overhead doesn't vary much iteration to iteration).

If the difference is significantly smaller than 20ms, then there is plenty of time for NPL to accept TCP connection and talk, so we're dealing with a different kind of problem. Have you tried a simple TCP example just as a sanity check?

[JoeSecurity]

Here's some extra detail to describe the error. When I run the NPL_*.vi on the remote target, there is no error code generated. However, when I attempt to run the Host_*.vi, the following error code is generated: "error 66 occurred at TCP Read in RTCW TCP Send Receive.vi->Host_*.vi" "Possible reasons: the network connection was closed by the peer."

[Bob_Preis]

On NPL_*.vi, check the error cluster right after TCP Listen and on both sides of TCP Send/Receive. The host side error sounds like it's trying to tell us NPL is failing somewhere.

If NPL attempts a write and fails, it will close the connection and cause the host to generate a connection error such as the one you're seeing.

[JoeSecurity]

Host still generates an error 66, however, after assigning a different tcp port (50000 rather than 12344) I was able to communicate with the NPL and ultimately the TCL for a while. After some idle time, error 66 is generated in the Host again. As you suggested, I checked the error clusters at the locations you identified in the NPL and there were no errors.

[Bob_Preis]

One possibility is that the host VI is sending so much data that NPL doesn't have time to read everything at the port. The default wait amount in Host and NPL is 100ms, but if NPL only gets enough juice to run every 101ms, it's period will actually be pushed up to 200ms (the next 100ms boundary).

If this is happening, I would expect to see the symptom you just described, where comm works for a while and then stops. Try slowing down host timing from 100ms to 150 or 200ms.

[JoeSecurity]

I've adjusted the timing in the host to various levels (the longest being 1000ms) and the same problem is realized. Any suggestions?