LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Application throws Error in Run VI Invoke node

Solved!
Go to solution

 

Hi All,

 

We are facing an issue with an application developed from LabVIEW 2010SP1.

 

Application Description:

In our application, there is a top level VI which tries to run VIs dynamically[using Run VI invoke node] from a particular folder. This folder is like a plugin - not part of Exe. This implies when the top level VI is launched, the plugin VIs under particular folder will not be in memory. When we try to run a VI dynamically from the  top level VI, the VI execution works perfectly in LabVIEW development mode.

 

Problem Faced:

When we created an EXE, it worked well in my PC [LabVIEW is installed]. We created an installer and tested in few other PCs.

[Non LabVIEW PCs – Win XP and 7]. In few PCs it throws the following error, when the plugin VI is run dynamically.

 

Error 1003 occurred at Invoke Node 

Possible reason(s):

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

Method Name: Run VI

 

We tried the following possible ways to find the reason for the issue:

 

1. Installed LabVIEW - Issue got fixed.

2. Installed .net 2.0 without installing LabVIEW - Issue got fixed.

3. But in one of the Windows 7 [Non - LabVIEW PC] in which .net was already installed, we faced the same error.

   Only after installing LabVIEW the error got fixed.

4. When .net 2.0 is uninstalled the EXE itself is broken.

 

We are not sure what is the Exact reason fo the issue. Anyone faced these kind of issues? Please share the solution. Thanks in advance.

 

Note:

1. The VIs which are dynamically called is a plugin and not a part of EXE.

2. These plugin VIs have no dependencies from vi library and is completely isolated.

3. We are not using any .net related objects in any of the VIs.

4. The plugin VIs use Call library function node in which a C DLL developed from Microsoft Visual Studio 2010 is used.

 

Thanks,

Meena

 

 

0 Kudos
Message 1 of 12
(5,850 Views)

Just connect one indicator in the path of dynamic called VI, then you will come to know what path it is choosing. Apart from this how you are selecting path, use application path directory. 

 

 

One more thing there is absolutely no problem with OS. 

 

Post your VI it will be easy to debug

--------------------------------------------------------------------------------------------------------
Kudos are always welcome if you got solution to some extent.

I need my difficulties because they are necessary to enjoy my success.
--Ranjeet
0 Kudos
Message 2 of 12
(5,829 Views)

Error 1003: This clearly indicates that the 'Dynamic VI' is broken and now you should check for the various reasons, why the 'Dynamic VI' is broken.

Also path of 'Dynamic VI' is not a problem.

 

One thing that you may try is:

-> First open just the 'Dynamic VI' in a new LabVIEW project and check for the 'Dependencies'.

-> Now if any of the item in 'Dependencies', other than what is listed in vi.lib (lets call it 'Dependency.VI'), is also a part of your 'Main Exe', then its a problem. Because when you will execute the 'Main Exe', say in a new computer other than your development computer, it will load all its dependencies including 'Dependency.VI' (and the path will be within the 'Main Exe', but when it will try to (dynamically) load the 'Dynamic VI', this VI will also try to load the same 'Dependency.VI' but from different path and that will cause a conflict. I had experienced this.

-> If thats the issue, you may want to rename (add suffix/prefix) to all dependencies of your 'Dynamic VI' which is common to the 'Main Exe'.

 

Hope this solves your issue.

 

Dependencies.png


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


0 Kudos
Message 3 of 12
(5,824 Views)

Hi ,

 

I work with Meena on the same project. 

 

The plugin VI is a simple VI with only a DLL call. It did not have any dependencies. In the project VI, no VI is listed as dependencies. With all these, we tried in a Win7 PC where our tool was installed as exe. It did not work. Later we installed LabVIEW, and the previously installed tool started working. This tells us something that LabVIEW is installing, that helps the dll call. 

 

Do you have any information about that?

 

Thanks,

Arvind

0 Kudos
Message 4 of 12
(5,802 Views)

Hi Arvind,

 

A shortcut would be that, you can instruct your installer to copy the same dll in c:\windows\system32 directory.

But the nice way is make sure that your 'Dynamic VI' and dll have same relative path relation as in the development computer... In other words check in the development computer, where from your 'Dynamic VI' is loading that dll file.... and when you keep this 'Dynamic VI' in new computer (test machine or actual deployment machine) make sure that the dll is at same relative path....!!

 

Let me know if this works....


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


0 Kudos
Message 5 of 12
(5,767 Views)

I was able to get to the next level.

untitled2.PNG

 

I tried wiring the path to the DLL call VI and right now the plugin VI is not broken but it returns error 13 (The file is not a Resource file).

Can you suggest me what will be needed to make the dll right? The DLL is built in C++.

0 Kudos
Message 6 of 12
(5,754 Views)
Solution
Accepted by topic author Meenalakshmi

Seems like, this dll iteself has certain dependencies...!!

Just think about:

-> Do you install any kinda driver to make this dll work...???

-> What is the source of this dll in your development machine??? have you installed any driver in the development machine....!! if so, you are bringing this dll (by including in the installer) to deployment machine but might forget to bring this dll's dependencies, that could be anything, a header file or another dll or something else...!!

 

Also instead of wiring a constant path to the dll, i would prefer 'forming a relative path' (well it has nothing to do with the current issue, just based on development guidelines)...!!

 

Form Relative Path.PNG


I am not allergic to Kudos, in fact I love Kudos.

 Make your LabVIEW experience more CONVENIENT.


Message 7 of 12
(5,740 Views)

Thanks all for your suggestions. The issue was fixed after installing Microsoft redistribution library, as the DLL was built in Microsoft Visual Studio development environment.

 

Thanks,

Meena

0 Kudos
Message 8 of 12
(5,619 Views)

Hi

could run VI by labview from different computer (PC)

0 Kudos
Message 9 of 12
(5,365 Views)

ekawaldi,

 

Your question has nothing to do with the older thread you posted in.  Please post your question as a new message thread.  And include some more details explaining what you are trying to do besides a single sentence.

0 Kudos
Message 10 of 12
(5,351 Views)