Launch code targeted to compact vision system

[DonRoth]

Following the NI tutorial on "Easy Ways to Launch Code Targeted to the Real-Time Controller," I am attempting to use the 'System Exec.vi' with an assembled command line in a 'LabVIEW for Windows' program on the host such that I can skip the steps associated with opening LabVIEW on the real-time target and manually downloading the code I want to run on the real-time target.

As such, in the LabVIEW for Windows host program, I use the command line to feed into the 'system exec.vi' with the exact following syntax (including quotations):

"C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" -target 192.168.10.15 "C:\Program Files\National Instruments\ROTH LABVIEW\DAPC-NICC_71\RT_grab_images.vi"

I perform this st
ep just prior to calling by reference the 'RT_grab_images.vi' to acquire a set of images using the compact vision system and transfer these back to the host. However, I get an error 7, file not found (I am assuming it is the 'RT_grab_images.vi' file that is not found). If I have already manually downloaded the 'RT_grab_images.vi' (which negates the advantage of using 'system exec.vi' with the command line shown), everything works fine.

Can someone comment on this?

Thanks,

Don

[Ken_S]

Hello Don,

I think I can clarify some of the information included in the tutorial �Easy Ways to Launch Code Targeted to the Real-Time Controller�, and maybe give you some ideas for how to accomplish your application.
Some of the wording in the tutorial is slightly misleading. The method of invoking the LabVIEW EXE with the target parameter and a VI specified will only open up LabVIEW with the specified VI targeted to the specified RT target. It will not download the VI to the target.

To download the executable you can go to the menu and choose Operate>>Download Application. This will download the VI to the RT target�s memory, but will not begin execution.

To programmatically do this there are two methods:

The first is detailed in the Tutorial you refe
rred to earlier under the section �Launching Executables on the RT Controller using Shortcuts.� This method involves turning your VI into an executable and creating a shortcut to launch it on the RT target instead of the Windows Host PC.

The second method is to use a procedure very similar to what you mentioned in your post. This method would be to FTP the VI to the RT controller (using the FTP VIs included in the LabVIEW Internet Toolkit) and then launch it using the Call By Reference method you described above.

I hope this helps. Please let me know if there is anything I can clarify or help with.

Ken S.
Applications Engineering
National Instruments

[DonRoth]

Instead of using the internet toolkit, would it not be possible to use a series of system exec.vi commands in succession to ftp on the host and thereby download the subject VI to the real-time target?

What would be correct syntax?

I ask this because indeed I tried ftping from a dos window previously but was not successful. I believed my syntax was correct (did not get errors) but subsequent code to launch the VI from the host did not meet with success.

Sincerely,

Don

[Ken_S]

Hello Don,

I�m not sure that it would be possible to use a series of system exec calls to use the standard Windows command-line FTP program to copy files to the RT target. You could certainly try this out and see though. I think the problem may be with the fact that the ftp program is console based, meaning once you start the ftp program you must input subsequent commands to the console to execute commands.

I tried to repeat what you were doing manually and got it to work. Here is the sequence of commands I used in the standard Windows ftp program:
ftp 10.0.34.65
User (10.0.34.65:(none)): anonymous
Password: blah
put c:\test\Untitled.vi
bye

This placed the untitled.vi into the root directory of the RT controller. I then
executed Untitled_host.vi on my host PC to start this VI. The most common problem encountered with using VI server in this way is making sure that the path on the RT controller is correct. In this case since the VI was copied to the root directory of the RT controller I used the path �c:\untitled.vi�.

I have attached these two VIs to the bottom of this email. I just put these VIs together very quickly to test out your procedure, so the host VI will actually only stop execution by hitting the abort button. These VIs should show you a way of successfully executing a VI via VI server, though.

I hope this helps you out. Let me know if there is anything I need to clarify.

Ken S.
Applications Engineering
National Instruments

[DonRoth]

Hi Ken:

This still did not work for me. The ftp portion executes with no errors but when I go to run the host program, it just hangs at the call by reference node (which likely means the VI could not be found on the CVS).

I tried some other strategy similar to yours using VI server to launch the VI (after ftp steps) from the host and received error 1003, 'VI not executable.' Right after this, I changed the execution target to the CVS system (using 'operate', 'change execution target') and the RT VI did not automatically pop-up (as expected if it was loaded).

I don't know if the CVS works differently than other real-time targets but it sure seems like it. Let me know if you have other suggestions.

Thanks,

Don

[Ken_S]

Don,

I tested this out on a CVS system and was able to get it working. The Call By Reference locked up because the Untitled.vi will loop until a stop button on its front panel is pressed. Obviously, the stop button cannot be pressed since we have no front panel interface to the VI.

I�ve modified my previous VIs so that the VI which runs on the target will run for 10 seconds and then exit, so now the Call By Reference Node should block for about 10 seconds and then it will stop execution.

As a side note if you are using LabVIEW RT 7.1, there is a new tool called the Real-Time System Manager which allows you to monitor which VIs are running on the RT target, along with seeing memory and CPU usage. 

Let me know if you have any problems with this.

Ken S.
Applications Engineering
National Instruments

[DonRoth]

Ok, this worked and from one of the other NI engineer (Michael Hoag), we discovered a way to programmatically execute this procedure using system exec.vi and a script file. For example, see the attached.

Below is more information from Michael if you have VI that you need to launch that has subVIs, and if you need to launch from other directories than c:\.

"Don,

Alright, with a little more persistance and work I think we now have a
working solution. I realized that the problem was that after copying the
VI over to the CVS, the VI was not in memory and was never "downloaded."
This means that all of the necessary subVIs (like all the standard LabVIEW
VIs from vi.lib) were never loaded onto the CVS and therefore the VI would
not execute when we used VI server, unless the VI had already been loaded
into the CVS' memory by targeting it.

To solve this problem, all we need to do is build a library (.llb) file for
our program that includes all subVIs, even those from vi.lib. This can be
done in LabVIEW, by going to the File menu and selecting Save With Options.
Make sure the "Include vi.lib files" option is checked and then create the
distribution. I have attached a new screenshot of my block diagram where
you can see that now I reference the main VI through the llb file (see the
path in the block diagram). In this case I placed it in the startup
folder, but that should not be a requirement. I also modified my script
file to take into account these changes.

I have rebooted the CVS several times to make sure nothing is in memory and
ran this new code. This appears to correct that last problem and should
get you moving forward with your application. Let me know how this goes
for you, and hopefully we have found a solution here.



Regards

Michael Haag
Applications Engineer
National Instruments"



"Don,

The error you are receiving when trying to call directory "C:\Program
Files\National Instruments\ROTH LABVIEW\DAPC-NICC_71" is definitely a
result of the DOS command prompt not linking the spaces and long
file/directory names. If you want to use that directory then you'll
probably have to figure out what the 8 character representation of those
files and directories are. For example if you want to get into C:\Program
Files\ then it will most likely be C:\Progra~1\. If you go to a DOS
command prompt (In windows go to Start >> Run and type in COMMAND), and
then type "dir /x" to display the directories, then the /x will have it
show the 8-character name for the directories and files.
"