Solved! Go to Solution.
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.
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.
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.
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?
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:
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.