Invalid input parameter for TCP vi

[Peter Tjeerdsma]

I'm programming a TCP-connection between the RT-module and the Windows-computer. At certain point I want to clear any errors before actually closing the connection. However when I run the application, Error 1 ("Input parameter is invalid") is returned. When I don't clear the errors, there is no problem. When I connect a error-constant, I get the same problem.

[rolfk]

---

@Peter Tjeerdsma wrote:
I'm programming a TCP-connection between the RT-module and the Windows-computer. At certain point I want to clear any errors before actually closing the connection. However when I run the application, Error 1 ("Input parameter is invalid") is returned. When I don't clear the errors, there is no problem. When I connect a error-constant, I get the same problem.

---

Typically error 1 would mean that you passed an invalid refnum to the function. You can do that easily in LabVIEW by opening a connection writing the refnum into a global and at some point end the VI hierarchy which did the open. Then start another VI hierarchy such as Reading from that refnum or simply closing the refnum and you get that error. LabVIEW does so called garbage collection. It remembers for each refnum who did open/create them and once the hierarchy of VIs who did goes idle it automagically closes those resources and disposes the refnum. The value stored in a global to be used by other function is now containing a refnum which is not existent anymore and you get error 1.

Rolf Kalbermatter

[finistere21]

so, what's the work around for this if you need to pass the ref. num. into a global and back into another .vi?

[Ben]

There is more than one solution....

Keeping the VI alive (don't let it go idle) is the simplest solution. Otherwise if you VI's have to go idel then you will have to start at the begining and open the connection again.

Ben

[finistere21]

how do i keep it from going idle? (i'm sequencing them in teststand.)

[Ben]

I'll assume you are loosing the connection on the Windows side.

You could have a test step that runs up-front that runs a VI in the bbackground that initializes the port and keeps the ref in an Action Engine but otherwise this VI the VI keeps running with calling the AE.

All other steps would access the Ae to get the connection info.

When the test seq is done kill the VI running in the background.

Ben

[finistere21]

Ben,

    your suggestion works perfect, i run a vi in a new thread with the telnet connection being held there, talk via another vi in the main seq. and terminate when completed. thanks

Kris