LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Open VI Reference Error when Using a LV Created EXE as ActiveX Server

Solved!
Go to solution

Making a long story short, I'm trying to create an executable in Labview that I can call from another Labview program via active x. I've been using the following article as my guide:

 

https://decibel.ni.com/content/docs/DOC-9647

 

It seems simple but I keep getting error 6945 saying that the VI name is no longer suffiencient. I've checked and rechecked the VI name that feeds VI path and I know it is correct. All I'm really trying to do is grab the VI reference so I can hide the front panel. Attached is a screenshot of the code and the error. Any thoughts?

0 Kudos
Message 1 of 10
(3,845 Views)

Is your "Hamilton Control Server.vi" owned by a library (lvlib) or a class (lvclass)?

TailOfGon
Certified LabVIEW Architect 2013
0 Kudos
Message 2 of 10
(3,829 Views)
No it's not. It should be just at the root of the executable. It's the startup vi of the executable.
0 Kudos
Message 3 of 10
(3,812 Views)
Solution
Accepted by thutch79

I would first try to run the executable and get the VI path by including "Current VI's Path" primitive in the VI. This is to make sure your calling path really matches what is in the executable.

TailOfGon
Certified LabVIEW Architect 2013
Message 4 of 10
(3,807 Views)

Thutch,

 

TailofGon realy hit this one on the head.  Once we have that information we will better be able to help you with your issue.

 

Regards,

 

J Newk
Systems Engineer
National Instruments
0 Kudos
Message 5 of 10
(3,782 Views)

I feel stupid now. I don't know why I didn't try that before. I've even done that same thing in the past. It was buried in folders I didn't expect. I'll have to go though the build spec and see why.

 

I did, however, find a better solution. What I'm trying to do in the long run was create a background process. This seems to be a much better solution.

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

 

0 Kudos
Message 6 of 10
(3,768 Views)
Glad it worked. I am curious as to why there was additional folders. From my experience, I know a vi gets kicked out of the executable into a folder next to exe if there is a name collision between classes (lv86). But never seen a folder created within exe, maybe it's a feature of newer version of LabVIEW ?
TailOfGon
Certified LabVIEW Architect 2013
0 Kudos
Message 7 of 10
(3,761 Views)

Hi all,

 

Tail, you are correct, this was changed in LabVIEW 2009.  This link has a description of changes made in LabVIEW 2009; the name conflict within applications is addressed about halfway down.

 

 

http://zone.ni.com/reference/en-XX/help/371361F-01/lvupgrade/labview_features/

 

 

Thanks,

 

David B

Message 8 of 10
(3,747 Views)

Thanks, dbell

 

This is such an awaited improvement and I am shocked that I did not know about it until now. I want to move to LV 2009 or later so that I do not have to expose bunch of VIs outside of executables. In LV8.6 if you use inheritance of LV Classes then conflicting name was inevitable as overriden VIs always have the same name as the parent method VIs (prefix does not fix it).

 

And I guess we need to add some comments on this page from PO  >> https://decibel.ni.com/content/docs/DOC-9647

TailOfGon
Certified LabVIEW Architect 2013
0 Kudos
Message 9 of 10
(3,743 Views)

Thanks for the comment and notes Tail, updating these really helps all users of LabVIEW.  I'm glad that this helped you out; I'm sorry that the information didn't get disseminated to you sooner.  Hope it helps.

 

Thanks,

 

David B

0 Kudos
Message 10 of 10
(3,724 Views)