LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1003 from Open VI Reference in executable on Windows 10

Solved!
Go to solution

Hi,

I have searched the forums and found several topics relating to this error however I have not found a solution for my problem which seems to be different to any I could find. 

 

I have a large executable that is built in LabVIEW 2011 and works perfectly on Windows 7. 

On Windows 10 I get the Error 1003, a screenshot of the error is attached. I have also a snip of the VI where the error occurs. It occurs in a Launcher VI which is trying to call the main vi, Eval.vi, when the error occurs. 

 

The main vi is "Always Included" in the application. And works perfectly on Windows 7 so is there something about how Windows 10 uses relative paths that could be affecting it? 

 

Any help would be much appreciated. 

 

Regards,
Cathal.

 

Download All
0 Kudos
Message 1 of 9
(5,545 Views)

I'm not sure why you would need to start an asynchronous call and then immediately call the same VI and wait on it to finish execution.  You probably have two instances running and when you exit the program, only one of them is closed. I'm not sure why it would run ok on Win7. 

 

I discovered that is not how the Wait on Asynchronous Call works.  I do notice that you don't close the VI reference after it finishes execution. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 2 of 9
(5,507 Views)

Cathal,

 

     According to NI's documentation, the oldest version of LabVIEW compatible with Windows 10 (32- or 64-bit) is LabVIEW 2015 SP1, so LabVIEW 2011 is likely to "fall short".

 

     You attached pictures rather than LabVIEW Code (such as a VI or a sub-VI created from the "interesting parts" of a VI), so I can't "play" with the images and icons you show to verify things.  However, you do know, I presume, that the Open VI Reference (which is the function giving you the Error message) requires a Strictly-typed VI Reference to be wired in to the top left connector when going to a Start Asynchronous Call, right?  Something I adopted when starting (with LabVIEW 2011, if memory serves) to use Start Asynchronous Call is to use a Static VI Reference (which removes the need for "Always Included", and which has a VI Path Property so you don't need to "construct" the VI Path, something that can get messy with Relative and Absolute paths).

 

Bob Schor

0 Kudos
Message 3 of 9
(5,477 Views)

According to this, it means the vi cannot run. It mentions a reason is that subvi's might be missing. 

 

Is daqmx installed?

 

Makes me think it has something to do with Windows 10's tightened security rules. An application does not have right in it's own program files directory by default. Try if this is the case by running the exe from another directory, or make sure all files\vi's are set to "unlock" in the installer. 

 

I'd use vi server to open the vi's front panel. It probably has a broken arrow. It might lead you to the. Reason why it's broken (remove stuff until it works).

0 Kudos
Message 4 of 9
(5,475 Views)

Hi Bob,

Thanks for the input. 

When you say a "Strictly-typed VI Reference to be wired in to the top left connector" I assume you meant the top middle connector, which is what I have, as the top left is for an Application reference. 

Using a Static VI Reference is good advice actually and I have implemented this. 

 

 

 

0 Kudos
Message 5 of 9
(5,457 Views)

This VI's only purpose is to call the main VI and display a screen, as it can take awhile to start, so the customer knows it is loading. The main VI then runs independently and the launching VI closes so as far as I can see there is no need to close the VI reference. I welcome a correction if I am wrong. 

0 Kudos
Message 6 of 9
(5,456 Views)

Thanks for the input.

 

DAQmx is not required by the application to run. 

I have tried moving the exe, also just using a built application without the installer and still see the same issue. 

 

 

0 Kudos
Message 7 of 9
(5,455 Views)
Solution
Accepted by topic author cathalcasey

The error seems to becoming from the .Net framework version that is being used. 

Windows 10 comes with v4.5 or later. LabVIEW 2011 uses v3.5. 

 

There seems to be an issue when using v4.0 or newer with an exe built using v3.5. 

Installing v3.5 on the Windows 10 fixed the error.

0 Kudos
Message 8 of 9
(5,452 Views)

@cathalcasey wrote:

This VI's only purpose is to call the main VI and display a screen, as it can take awhile to start, so the customer knows it is loading. The main VI then runs independently and the launching VI closes so as far as I can see there is no need to close the VI reference. I welcome a correction if I am wrong. 


I'm looking at the AsynchronousCallAndCollect.vi example from the help file.  It states this:

Close the reference after the Wait On Asynchronous Call has completed.

When performing an asynchronous call and collect, closing the VI reference will abort any currently running calls and prevent serialized calls from starting execution. This is different from the behavior of call and forget where the target VIs will continue running to completion.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 9 of 9
(5,440 Views)