update deployment

[wireguy2]

I have a question regarding deployment of a test stand system.  I am running Teststand 3.1 and LabVIEW 7.1.1 and have been able to successfully build a deployment and install it on a target machine.  With the size of my system building the deployment and installer takes about 40 minutes.  The question is:  If I make a change to one of the deployed vi's is there a way to "copy" or somehow put it on the target machine without having to rebuild the entire deployment.  So far between myself and tech support we have been unsuccesful in doing this.

Thanks

[Thaison_V]

Hi wireguy2,

I hope you're doing well.  I had a few clarification questions for you.  When you say you are building a deployment and installing it on a target machine, are you talking about a LabVIEW executable?  If so, is this being installed on a Windows target, or deployed to a Real-Time target?  I definitely understand the pain of compiling this if it takes 40 minutes to do so.  Unfortunately, if this is an executable in LabVIEW, I don't believe there is a way to modify the individual VIs contained in the executable without recompiling the entire package.  At the moment, the only work-arounds I can think of is by using VI server to run a VI programatically on the remote machine instead of creating an executable, since this will allow you to still maintain invididual VI files, or you may be able to compile the "often updated" section into a .dll, and call this from your executable with the call library function node.  You can then simply replace the .dll each time to update this.  Let me know if this helps!

Thaison V
Applications Engineer
National Instruments

[wireguy2]

Thanks for your reply.  This is a teststand deployment.  Building executables in LabVIEW is something we do here routinely for our "non teststand" systems - the issue is with putting a modified labview vi into a teststand deployment.  Basically we are trying to get away from needing the full blown teststand and labview on these systems.  If, however, rebuilding a deployment any time we do a simple vi change is the only way, we will probably keep the environments on the machines

Thanks again

[Dennis_Knutson]

I'm not very familiar with the TestStand deployment tool. I use LabVIEW with TestStand 2 and seldom have to do anything except update a single .seq file in a single netwok location, can you explain what the deployment tools does to the LabVIEW code? Does it create an llb file and are the main VIs called by the sequence separate from the llb? If that's the case, then you should be able to update the llb quickly without spending 40 minutes.

I guess I don't understand the relationship between deploying a test sequence and having the development environments installed. You should only need the development programs on a system if you need to debug a sequence or test step.

[Josh_W]

Wireguy2,

Part of what the TestStand Deployment tool does is re-link all of your VIs.  Because the LabVIEW Development System might not exist on the target machine, all VIs, including any VIs from the VI library, need to be included with your distribution.  This is why you'll find a Support VIs folder in your image folder after you have built your distribution.

The recommended way to update your distribution is to re-build the entire distribution.  If you just make changes to a VI, and then copy that VI to your target machine, chances are that it will not run, because all of its links are still pointed to the <LabVIEW>\vi.lib folder which might not exist on your target machine.

Josh W | National Instruments | Applications Engineering

[Morgue]

I have the same problem as Wireguy2. What if you open the VI you want to make changes to, where it lies on the target machine? Will LV relink it to support-VI's on my machine anyway? Sorry to awake an old thread.

/Vedeja

[RayFarmer]

Hi,

If you open a VI, first it will try to link to the VI's it was deployed with, if it can't find them then it will use the search paths to try locate another copy. The search paths it uses is not the ones detailed by TestStand but by the Labview ini file.

Hope this helps

Ray Farmer