NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

remote vi first call very slow

Solved!
Go to solution
My sequences include multiple call to vi's on a PXI chasis.  The PXI is running Labview.  The first time a step with a remote vi executes, nothing seems to happen for as long as 30 seconds.  Subsequent  executions of the same step occur instantly unless the module code is unloaded.  My hunch is that PXI Labview is searching for all the subvi's of the remote vi.  Optimizing the PXI search path may have helped a little.  But what helps enormously is to explicitly call the PXI Labview vi server within a code module running locally using vi references.  In this case even the first call is apparently instantaneous.  Has anyone experienced this?  Does anyone understand it?
0 Kudos
Message 1 of 9
(3,969 Views)

Hi Ken,

 

To really answer your question, I need some clarification.

 

1) What versions of TestStand and LabVIEW are you using on each computer?

2) The host machine must be running Windows, but what is the remote machine? Windows? RT?

3) In your VI call, under advanced settings, do you have the remote path specified? I ask this because if your remote machine is an RT machine and you don't specify the remote path, then TestStand will automatically download the file to the remote machine (which could take a while).

4) When you said you made a VI that uses VI references, did you mean you use a "wrapper" VI to communicate with the remote VI?

 

Another possibility is that when you call a VI on a remote machine, TestStand actually creates a "wrapper" VI on the host machine to use VI Server at runtime, but this should not take near as long as the time delay you are seeing.

0 Kudos
Message 2 of 9
(3,942 Views)
Forgot to add something. Number 3 from my previous post only applies if you are using LabVIEW 7.1.1 RT. LabVIEW 8.0 and later RT module does not support downloading VIs automatically.
0 Kudos
Message 3 of 9
(3,934 Views)

Thanks for your interest.  Here is some additional information.

 

The PC running TestStand and the PXI controller are both running Labview 8.x (don't recall x off hand).  They are both Windows machines.  There is no reat time (RT) operating system involved.

 

I've specified the path in the advanced settings.  The path is identical on the PXI controller and the TestStand PC.

 

Yes, by vi references, I mean a wrapper vi which gets an application references on the PXI, then a vi reference on the PXI, and then invokes the vi on the PXI.  This approach runs 10 times faster on the first execution.

0 Kudos
Message 4 of 9
(3,920 Views)

When we make a remote VI call, we load the local VI into memory. Then we use that VI to programmatically create a wrapper. The problem that you are probably running into is that loading the VI using the runtime engine may cause searching for dependencies which could take awhile. Creating the wrapper should not take awhile.

 

There are a few things you could try:

 

1) Create a source distribution for the local VI, and then point the module to that distribution. This should make the local VI load faster and might resolve the loading issue.

2) Make a dummy local Vi with nothing in it, but with a matching connector pane to the Vi that you want to call. If the connector pane matches exactly then the wrapper that we will create from the dummy VI will be exactly the same as the one that we would create for the local VI, except since the dummy will be empty, it will load very quickly.

3) Another option is using the wrapper VI you have already created. If you make your own wrapper though, you would be responsible for updating it if the connector pane changes.

0 Kudos
Message 5 of 9
(3,890 Views)
Solution
Accepted by topic author ken@ngc
I have now converted many remote VI calls to local prototypes but the actually VI path on the remote server specified in the advanced pane.  I'm getting substantially better performance.
0 Kudos
Message 6 of 9
(3,794 Views)

What do you mean by "explicitly call the vi server within code module running locally using vi references" ? Do you mind posting some good vs bad example to help us understand it?

 

Appreciate that!

0 Kudos
Message 7 of 9
(3,289 Views)

Hi htan,

 

I believe what ken was refering to when he mentioned explicitly calling the vi from a local code module was that he had created somewhat of a wrapper VI which uses a VI reference in order to call the remote VI.  He then instead referenced his local wrapper VI from his Teststand sequence.

 

I will try to address your question posed to CorbinH on how his first suggestion will be beneficial.  I believe his suggestion on creating a source distribution was aimed at getting all the VI dependencies in the same location on the local machine.  This would hopefully allow all of the VI dependencies to be located quickly as they will all be located in the VIs current directory rather than searching in various directories and on the remote machine.

 

Creating a Source Distribution in Labview:

http://digital.ni.com/public.nsf/allkb/F3DC40A6E3F3B25B862570AD005D1D3D

Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/
0 Kudos
Message 8 of 9
(3,259 Views)

The explanation above is indeed what I meant with regad to "local code module" - it is a wrapper.  We are still using this approach although I am still confused exactly why the direct call is not faster.  Have not had time to investigate further.

 

Ken

0 Kudos
Message 9 of 9
(3,254 Views)