Communicating programatically with RT PXI via FTP?

[kehander]

Having finally escaped the lab for a week or two, I have come up with a new idea that I've been pondering:

I need to communicate between two LabVIEW programs, one running on an RT PXI and another on a Host PC running Windows. Shared variables and VI Server seem to have a number of different problems, unfortunately.

But it occurs to me: What if I have a program running on the Host PC that opens an FTP session (using the Internet toolkit) on the RT PXI's built-in FTP server, and then constantly monitors a particular directory for new files? Then when I need to communicate something to the Host PC, I could just have the program on the RT PXI write a file to that directory, and the Host PC could be made to interpret the new file's name as a command.

The advantage to this is that no fancy networking setup is necessary on the RT PXI, since the FTP server is set up automatically. Has anyone here tried this approach before? Is it too obvious? Or is there just some better way of doing this that uses a similar methodology?

[Nadim R]

Hi Kehander,

I believe that your idea should work in theory, since the internet toolkit is supported with LV RT 5.1.2 and above.  However, it may be more complicated to implement such as system rather than just using shared variables, TCP or UDP for the network communication.  If speed is not a factor for your application, I would use shared variables.   

Advantages of using network shared variables are that the programming difficulty is very simple and that the determinism between your host and target increases when using RT FIFOs.  Shared variable protocol, however, is not the fastest (as compared to TCP or UDP).  When speed is a factor, SVs may not be the best solution.  Also a caveat with shared variables is that it can only be used with LabVIEW versions 8 and higher.  A tutorial on using SVs is shown in this link. 

If speed is a factor for your application, then I would consider using TCP or UDP communication.  Like you said, however, the programming difficulty increases when using these protocols.  However, there are many examples in the Example Finder and that use TCP or UDP (under Networking).  Keep in mind that these protocols are non-deterministic.           

I hope this helps.

Regards,

Nadim

Applications Engineering

National Instruments

[Olli]

Hi Kehander,
I'm actually setting up a distributed measurement network with 3 Fieldpoint devices, 1 PXI and 6 Keithley 2701E. First trials with shared variables lead into frustration. Now every communication is done via TCPIP...Even the clock setting of the keithleys which cannot actively communicate via NTP with a time server is accurate enough for our application (max about 20 ms....otherwise they use to drift a few minutes per day out of time!).
Ciao
Olli

[kehander]

I had the impression that I would run into the same kinds of problems working with the raw TCP/IP communications VIs that I have experienced with shared variables - plus there would be all kinds of added hassle with type casting and connection IDs to worry about too.

That's why I thought my idea of communicating via FTP was such a good idea - it just appears to be so simple in concept. Also, if for some reason you need to intercede manually in the program, you can just fire up an FTP client and manually put a new file into the directory of commands without having to touch LabVIEW at all.

[Jarrod_S.]

I'm by no means a FTP expert, so what I say may or may not be relevant, but I would worry about two issues with your design:

1. Your RT VI notices a new file is present and tries to read it, but the FTP tranfer hasn't completed yet. I'm not sure what the effect would be of trying to read a file that's still being written. You might get a permission error or incomplete data. Not sure...
2. Speed. You were worrying about Shared Variables and their performance, but I would be very surprised if the overhead of transmitting a file, and opening and closing it on both ends would be any quicker if not much slower. The only advantage I would see is if you wanted to transfer a lot of data at once, and rather than storing the whole thing in memory,  you only wanted to access random sections of it at a time. A file would be preferable in that case.

Keep in mind if you do reconsider Shared Variables (and I'm not trying to market them or anything, any solution will do 😉 ) that you can use the Variable Manager (Tools >> Shared Variable >> Variable Manager) to write values to deployed variables directly, much like you wanted to do with an FTP client for debugging purposes.

[kehander]

It wasn't so much performance that was bothering me with shared variables as much as it was sorting out the flow control.

You raise some interesting points; my initial thought was that by communicating data via the filenames themselves (and not the contents of the files) I might at least avoid trying to read a file that was still being written.