Error 64: Network connection is not yet established?

[JoeSecurity]

I've also discovered something new. In the NPL, after the TCP Send/Receive has completed its first "send (front page update via "Writer" case)" an error -2202 occurs in the "Reader" case for each of the controls being read in. It would seem that the control values are read in immediately after the indicators are updated. A short delay after the last error -2202, a new error window pops up, error 66. Ideas?

[Bob_Preis]

Perhaps the behavior is related to this Knowledgebase article?

Locate the FIFOs of any controls/indicators that are in a nested case structure and try initializing those FIFO names before the normal priority loop starts. Or move the controls/indicators to a location in the loop that executes on the first iteration.

[JoeSecurity]

I have moved my controls to the outer most region of my main control loop. Error 2202 has disappeared but now I get error 56 after running 1 iteration of the loop. Your advice has been fantastic so far, any ideas for this?

[Bob_Preis]

Not sure why NPL would timeout when trying to talk to Host. If you could pare down the VI to exclude I/O and post it, I will have a look at it on my machine.

By the way, that problem where the FIFOs don't initialize will be fixed in the next release of LabVIEW RT. The fix will force initialization of all FIFOs (even for controls/indicators that are inside non-executing cases).

[JoeSecurity]

After removing the file I/O sections of my example in preparation of sending the VI to you, I've noticed that the comm. seems to work great now. I have reason to believe that perhaps the functions that I'm using to check the daq channel for an appropriate level trigger are blocking the loop from executing at it's desired rate. Any ideas?

[Ben]

How does your memory look with and without the file I/O sections?


Ben

[Bob_Preis]

If you have parallel loops running traditional NI-DAQ, they will block each other. In fact if you have parallel calls to DAQ VIs anywhere, they can potentially block each other...even if they are in the same loop. Avoid this situation by enforcing data flow with the error cluster wire.

[JoeSecurity]

Excellent tip. The data flow concept is working out great. I've created "dummy" data flows to force the RT s\w to flow in a particular sequential order within the same loop. Thanks for all of your help in this post!