Jump to content
News about the LabVIEW Wiki! Read more... ×

SeriousGeorg22

Members
  • Content Count

    1
  • Joined

  • Last visited

Community Reputation

0

About SeriousGeorg22

  • Rank
    One hit wonder!

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    2016
  1. 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.
×

Important Information

By using this site, you agree to our Terms of Use.