Missing link to the Write Key.vi LabView file after switching LV Server from Development system to RTE

[MimiKLM]

Hi,

TS4.2 LV8.6.1

I've got a strange TS behavior. The whole code works OK under the Development System. But when I switch the LabView Server from Development System to the LabVIEW Run-Time Engine then, during calling one of my VIs (action step calling the LV adapter) I've got the 'search for vi' window opened looking for the Write Key.vi (one of internal LV VI). Finally the Write Key.vi file is found and TS is happy however I don't want it to happen on the production floor.

Is it a bug, or I have to switch a kind of option or something?

Why it doesn't happen under Development Environment? What is the mechanism?

K.

[John_M.]

Hi MimiKLM,

This can arise in situations where some of your VIs are saved in one version of LabVIEW and some in another version. Although the development environment can run VIs saved in different versions, the run-time engine requires that all VIs be in the same version. As a result, in your situation, the run-time engine may be having to go look for the correct version, while the development environment can use any version. If this is the case, try mass compiling your project, which will compile all subVIs into the same version.

Also, for some additional information about mass compiling, take a look at:

What Does Mass Compile Do in LabVIEW?

Mass Compiling VIs - LabVIEW Help

Best,

John M

[MimiKLM]

We are using only one version of the LV 8.6.1

The project (all VIs called by teststand) was created in version 8.6.1 from scrach.

No third party SW/libraries have been used.

Why then?

[AllenP]

This happens because the LabVIEW Runtime Engine does not give paths to VIs that are located under vi.lib, such as the one above.  TestStand will automatically add those paths for you if you have LabVIEW Development System installed.  Since it is using a search directory rather than using the known path of the VI, it is slower and brings up that dialog before eventually finding it.

It is recommended that you deploy your system using the Deployment Utility to move everything to the factory floor.  This will allow the VI to run with only the LabVIEW Runtime Engine installed.  The Deployment Utility will automatically copy and re-link to any VIs in vi.lib to a local directory so that your VIs will reference that copy.

Allen P.

NI

[MimiKLM]

---

@AllenP wrote:

This happens because the LabVIEW Runtime Engine does not give paths to VIs that are located under vi.lib, such as the one above. 

Allen P.

NI

---

First of all, sorry for the delay.

Maybe it seems to be a post which shouldn't be on this forum however it is strictly connected with the thread. So, may I ask what is the reason why LV RTE doesn't give paths to VIs in vi.lib folder? I don't think so it is a bug  it is rather a feature of LV itself  which I'm not aware of.

Could you tell me what VIs from the LV Functions Palette are stored in the vi.lib folder? What are others popular functions are there? Is this feature (not giving the paths) of LV kept for the legacy issues?

K

[MimiKLM]

---

@AllenP wrote:

This happens because the LabVIEW Runtime Engine does not give paths to VIs that are located under vi.lib, such as the one above. 

Allen P.

NI

---

[MimiKLM]

First of all, sorry for the delay.

[MimiKLM]

Maybe it seems to be a post which shouldn't be on this forum however it is strictly connected with the thread. So, may I ask what is the reason why LV RTE doesn't give paths to VIs in vi.lib folder? I don't think so it is a bug  it is rather a feature of LV itself  which I'm not aware of.

[MimiKLM]

Could you tell me what VIs from the LV Functions Palette are stored in the vi.lib folder? What are others popular functions are there? Is this feature (not giving the paths) of LV kept for the legacy issues?

[MimiKLM]

K

[AllenP]

It doesn't give a path because the runtime engine may exist on a system that does not have vi.lib.  The LVRTE does not have a vi.lib to reference.  As a convenience, TestStand will add those paths to search directories.

Generally you can tell if a node in LabVIEW is in vi.lib if it can be opened by double-clicking on it.  The primitives are not part of vi.lib and cannot be double-clicked.

[MimiKLM]

Ok,

Sorry for my LV ignorance but:

1. why Write Key.vi being a part of the main LV distribution is kept in vi.lib folder? why the distinction is made amongst the main distribution 'internal'  VIs?

2. what are the other 'important' and popular VIs kept in vi.lib folder?

3. what about instr.lib ?

4. becaose I don't want to use TS to generate the distribution, can I do it in LV? Will the distribution prepared this way work?

[AllenP · Accepted solution]

1)  Most complex nodes in LabVIEW are stored in vi.lib.  This is not uncommon.  Only the very basic elements are not (add, subtract, array functions, etc...).  They are usually yellow and you cannot open them.

2)  They need to go somewhere, and vi.lib is the standard location for all built-in VIs. 

3)  instr.lib is very similar to vi.lib, just a different location.  LabVIEW stores a relative path for VIs that get called in here.  This path does not exist with the runtime engine, although TestStand will add it to the search directories if LabVIEW Development is installed.

4)  While it is possible to use LabVIEW to do this, there are more ways to get in trouble since doing it this way would never update your sequence or find problems that would be unique to TestStand.  Is there any reason why you don't want to use the TestStand Deployment Utility?  Behind the scenes, TestStand is calling into the same framework as LabVIEW for deployment, but doing it with more knowledge than LabVIEW alone would have.  This can be done, but there are more considerations and potential issues you can run into.  Unless you have a good reason for this, it is usually not advised.

I would recommend reading the chapter on Deployment in the Reference Manual here (chapter 14):

https://www.ni.com/docs/en-US/bundle/373435e/resource/373435e.pdf

[MimiKLM]

Dear Allen,

Thank you for your explanations. Right know I know where I am.

Yes there are two reasons why do not use TS Deplyment Utility:

1. Bad experience doing so in the past,

2. The sequence is calling few different subsystems (LV adapter) being developed by different developers. Is better to have independent code distributions.