TCP VIs don't work from Executable?

[SeriousGeorg22]

Hi Folks,

 

First off, I'm very new to LabVIEW and programming in general, so let me apologize in advance for my knowledge deficiencies. I'm working with a device that I can talk to with serial communications or via telnet. I developed a set of VIs that allow me to specify which method I'd like to use for communications (serial or telnet) and then open, read, write, or close the connection using either the VISA VIs or the TCP VIs respectively. I ran into an issue in that I didn't know the amount of bytes to read for the TCP Read VI because the device I'm talking to has a very large list of possible commands (and the response length may change at the whim of a developer), but I found a neat solution here. This last detail becomes important later.

Anyway, everything seemingly worked great within the LabVIEW development environment. Then I had to rip an executable for an end-user. From the executable telnet doesn't work at all. Worst of all, I don't seem to get any sort of error out. In trying to resolve this issue I did some Googling and found the following post suggesting that the issue might be that the VI that opens the telnet session needs to keep running. I also found this post and I think rolfk's answer gets at the root of my problem ("Just be aware that LabVIEW garbage collects all its refnums as soon as the hierarchy that opened that refnum goes idle"). As far as I can understand, my issue is that as soon as my subVI that opens a telnet session finishes the refnum it returns in the form of a TCP connection ID (to be used by the write, read, and close VIs) gets trashed. So I try creating a little test VI where I use the TCP VIs all within a single block diagram and it seems to work fine as an executable. This gives me a potential solution, except that, as I indicated above, I don't know the number of bytes to read for the response to any given command and have been using the TCP Get Raw Net Object VI as part of the solution to that problem.

I guess my question is, how can I keep the VI that opened the telnet session running (and not just in memory)? I'm content to move the TCP Open VI out to an upper-level VI (and have all read, writes, and the closing of the session handled in a subVI), but the calling VI seems to suspend as soon as a subVI starts executing. I've tried digging around in the execution settings within the VI properties, but nothing there seems to be what I'm looking for.

Alternatively, I've considered using the VISA VIs to handle the telnet session. The only issue I have with this is that I still need to know the number of bytes to read. I think I could use my current solution provided that I can typecast from a VISA resource to a TCP connection ID (as the TCP Get Raw New Object VI expects). I've done some reading that indicates this is possible, but I haven't been able to figure out how to do it.

I greatly appreciate any help anyone can provide with this issue.

 

[infinitenothing]

Are you using async VIs? I find it unlikely you have some refnums getting autocleaned unless you do.

You have a case where the com works and one where it doesn't. Try and figure out what intermediary step breaks the functionality.

Can you read one byte at a time until you get the termination character? Maybe someone with more telnet experience can weigh in.

I'm not clear why you wouldn't be getting an error. In debugging you have to check everything (error codes, refnum IDs, counters of how often a given subVI runs, etc) to see the smoke to tell you where the fire is. You might have to modify VIs you received from outside sources. 

Edited September 18, 2017 by infinitenothing

[Rolf Kalbermatter]

Just as infinitenothing has mentioned, unless you use the Run VI or the Start Asynchronous Call VI server method, it is highly unlikely that you run an independent VI hierarchy in your application that could cause the refnums to be autocleaned.