Programmatically download RT programs

[acoustics 2]

What I want to do is to have an extendable, flexible and easy to use PXI RT controller software environment, where the RT programs do not reside on the RT platform, but on the host computer (which is required in this case).

So, my concept is to have small flexible functions for the RT controller implemented in separate "RT"-Programs. This programs reside on the host. To each of the programs there is a host program containing the user interface. The communication is done by tcp. So, to get the right RT counterpart, I use the SystemExec.vi on the host calling "rt_program -target my.ip.address.numerical -quithost". This works fine, the connection is set up, the rt_program is downloaded into memory only and startet, the host load proc
ess exits and the host user interface can connect to the rt_program.

But, if I call this a second time, the download process runs differently. The download process finds that there are some vi's in memory, uploads a list of them and waits for user interaction. I have to start the rt_program manually and have to quit the download process without unloading the vi's manually to continue 😞

What am I doing wrong? How might another solution look like?

[aasenjo]

Hi,

I don't believe you are doing anything wrong, this is expected behavior, at least for now.

I can suggest a couple of options for what you want to do:

1) Create a Development Distribution llb. Go to File -> Save with Options -> Check Development Distribution -> Make sure you also check the Include vi.lib VIs checkbox. Once you save your llb you'll have a single llb that contains all the necessary VIs. FTP the llb to the target and open the top level VI using VI Server. The whole process can be automated but you'll probably have to build a host and target application (the host will ftp the llb to the target and then let the target application know where to find it, the target application will open it using VI Server)

Caveats:

- llb files can get very big
- You will not be able to see the front panel of the loaded VI directly. You can use Remote Panels or build your own user interface VI that will run on the host and communicate with the target VI over VI server or any other Networking protocol.


2) Create a host application that, once instructed to download a VI to the target, will obtain a list of all the VIs in the hierarchy. (Use the Callees VI Property node) then it would FTP each of these VIs to the target, instructing a dedicated target application to open them. This way you save on storage space when multiple applications share subVIs.

Caveats:
- Increased complexity
- Cannot view the front panel of the downloaded application directly.


Both of these options require moderate knowledge of VI Server calls. Refer to the LabVIEW USer Manual, chapter titled "Programmatically Controlling VIs".

We actually use both of these approaches to build automated test suites for internal use. Another alternative is to use Testand 3.0 which allows you to programmatically download and execute VIs on an RT target. Although Testand was specifically built to be a Test Manager environment, it might fulfill your needs of programmatic execution under RT.

I hope this helps,

Alejandro
LabVIEW RT R&D
National Instruments

[acoustics 2]

Hello Alejandro,

thanks for the information. I do not have any problem with not seeing the RT vi's front panels - the are not intended as an user interface anyway. But my major concern is that the software should NOT be downloaded on the hard disk drive of the RT controller.

I have a small startup program on the RT controller harddrive (this is allowed 🙂 to do some first HW initialisations. This works fine and the vi's are not in memory after the program finishes. So, the startup exe really quits. What do I have to do with the later programs/vi's to reach the same result? Having a vi that terminates normally gives an "idle" vi in the RT engine, and this causes my later problems. So, how to remove the vi's finally at the end of the program run not t
o leave them idle? Stopping them with a "stop.vi" at the end does not change the situation. Stopping the RT vi with an "exit.vi" to exit labview crashes my RT system. Calling the "abort vi" method on a vi itself also crashes my RT system.

So, all I am really looking for is a way to exit a "RT" program (targeted to the RT controller from the host) in a way comparable to how a startup program exits, i.e. without leaving "idle" vi's in memory, without rebooting the RT controller.

I will have a look into Teststand on monday, but any additional information on the problem is welcome.

Thanks in advance.

[RobCole]

I think that part of the problem here is that you are targetting to the RT system. Targetting is designed for debugging a program so you can run a program on the RT system and then later use LabVIEW to make that your execution target and link to the VIs running without stopping the program. What you are seeing is what it was designed to do.

I might build (read: have built) a small "client" VI (RT) that never ends, but waits for a TCP connect to tell it the name of a program to run then run that program with System Exec.vi (okay, I actually used dynamically loaded VIs). That way you could build an FTP client into your GUI (PC side) and send whatever program into the RT and tell your small app what the name of the program is. A little bit clumsy but it does wor
k.

Rob