How do I programmatically deploy a VI to a target?

[Keith]

I'm building a generic test application for a customer. We use a configuration (XML) file format that is basically a big cluster of all the things we need, such as an array of channel configuration clusters (name, physical channel, calibration, etc.), an array of filter settings, sample rates, log file names, etc. The RT PXI target VI starts and waits for a configuration. The main VI starts and prompts the user for the test configuration file. It's loaded in and sent to the target, which initializes all the devices and channels and starts logging and transmitting data to the front panel for display.

This is all fine a good, but right now the test criteria are hard-coded in the target VI and that ain't good. The customer wants to be able to specify arbitrary test criteria, which may vary from test to test. The test criteria could involve averaging, FFT, etc. so I had this crazy idea to use a separate VI to represent the specific test criteria. The config file would have the file name for the test criteria VI. The end user would develop the test criteria VI to suit the particular test needs. Then somehow, the VI would get to the RT PXI target and execute. I know how to reference the VI on the host and have developed a simple working prototype of the concept, as long as I'm only working on the host PC. But I don't know how to get the VI to the RT target programmatically at run time. I know I could FTP the file over but that wouldn't cover all the dependencies. Besides, surely there is already a way to get a VI and its dependencies to the target.

If this isn't possible, the only other approach I can think of is to use a string expression that represents all the test conditions. BTW, I tried this one using an eval formula node but that doesn't support boolean expressions. I would have to come up with my own expression parser (yuck!) and it would still be much more limited than the VI approach. So I really would like to find a way to get the VI method to work!

Thanks.

[Neville D]

The only way is to ftp the VI and then use VI Server within your main app to call the new plug-in VI that you have ftp'ed.

But why don't you just cram all the plug-in VI's you would need into an exe and then just leave the exe once and for all on the RT target? Then call what you need from the ini file or commands from the Host or any other architecture.

There is an example VI on the NI site that downloads a VI and then runs it with VI Server. You need the Internet Toolkit installed to run that. But be warned, this is not a bullet-proof method. I have been doing this for a while now, and running a VI remotely with VI Server is flaky. It may or may not work and frequently throws Error 66 (when it has been working fine before). My current work around is to try again till it works or try a reboot which seems to clear things up.. (not very scientific to say the least..)

There is another example on the NI site that uses a Client Server App to do what you are doing, by running a particular process (say a different waveform to generate) based on a command sent. This is now much easier with shared variables.

N.

[Keith]

Well, I'd love to bundle up the test criteria VIs in an exe but I'm delivering a system that allows my customer to write their own VIs. So I have no idea what they are up-front.

[Neville D]

OK, then just get them to build their app into an exe which your RT app can call as a plug-in. They can drag their exe into the RT target using windows explorer as an ftp interface. But it can get complicated in terms of inputs and outputs.

Its really difficult writing an app for OTHERS to modify. I know customers start out saying "I want to be able to change this", but in reality they probably won't touch it, or will complain that the process is too complicated.

N.

[Rolf Kalbermatter]

QUOTE (Neville D @ Feb 5 2009, 01:27 PM)

The only way is to ftp the VI and then use VI Server within your main app to call the new plug-in VI that you have ftp'ed.

But why don't you just cram all the plug-in VI's you would need into an exe and then just leave the exe once and for all on the RT target? Then call what you need from the ini file or commands from the Host or any other architecture.

There is an example VI on the NI site that downloads a VI and then runs it with VI Server. You need the Internet Toolkit installed to run that. But be warned, this is not a bullet-proof method. I have been doing this for a while now, and running a VI remotely with VI Server is flaky. It may or may not work and frequently throws Error 66 (when it has been working fine before). My current work around is to try again till it works or try a reboot which seems to clear things up.. (not very scientific to say the least..)

VI Server on RT targets can have bad side effects. I enabled it recently on a CompactFieldpoint 2020 controller (one of the slowest there is I believe) and the whole application started to behave erratically since the processor load got so high that it could not keep up with running my normal VIs. And I had only planned to execute a VI or two remotely through VI server to send and retrieve some data. Turning VI server off and integrating that data transfer into my already existing LabVIEW TCP/IP server protocol on the controller made everything go smooth again. So if your CPU is not very powerful VI server certainly can cause problems and your timeout errors might be the reason for that.

This is probably not gonna work since it would require building a new executable after every modification by the client but there is a VI library on the NI site called "System Replication" that allows downloading an executable and enabling it to be run from the host. I'm currently still experimenting wth this but it seems to work as I had hoped.

Rolf Kalbermatter

[Neville D]

QUOTE (rolfk @ Feb 9 2009, 11:43 PM)

VI Server on RT targets can have bad side effects. I enabled it recently on a CompactFieldpoint 2020 controller (one of the slowest there is I believe) and the whole application started to behave erratically since the processor load got so high that it could not keep up with running my normal VIs.

I have a number of PXI 8187's running LV-RT. They are based on the Pentium-M mobile single core processor, with reasonable performance, but like I said, VI-Server performance is still shaky.

N.