回复： EXE I built unable to open reference to VI with MathScript Node in it

[zach_listen]

Hi Everyone,

First off, I'm using Labview 8.5 on Windows XP.

I have two VIs. One called "Main Instance.vi" and the other is called "code.vi". The Main Instance vi is very simple. It opens a reference to code.vi. Using this reference, it dynamically calls code.vi using the "Call by Reference" node.

The code.vi is also fairly simple. On this VI's connector pane, I have two inputs "a" and "b" and one output "c". All are of double data type. These controls are wired to a MathScript Node where the code inside is simply:

c = a + b;

So the idea here is that I am using the Main Instance VI to dynamically call and pass two numbers to code.vi. code.vi adds these two numbers via MathScript and returns the answer back to the Main Instance VI.

This all works fine and dandy within LabView. However, when I build Main Instance.VI as an application, I am no longer able to open a reference to my code.vi because it has a MathScript Node in it. I put error indicators on the front panel of Main Instance VI to monitor the Open reference and Call by Refernce nodes. As VIs running in Labview, I get no errors and everything works fine ("a" and "b" are added and "c" is the correct answer). When Main Instance is an exe I get errors 1003 for the open reference function.

I have attached screenshots of the Vis as well as the VIs themselves.

Any guidance is appreciated. Keep in mind that I have to use Labview 8.5 as this is just an example of a bigger problem that is occuring in our software while developing a solution for a customer. Right now our software is compiled in Labview 8.5.

 

[ttrr]

Hi zach_listen,

A workaround is to Always Include code.vi when you build application. I try LabVIEW 8.6 and it works.

You can find help topic about Always Included at here.

[altenbach]

As ttrr said, you need to include Vis that are called dynamically. It's not really a workaround, but the right way to do it! Imagine a case where the VI name is generated programmatically at runtime. Sure, LabVIEW could make an exception if the VI name is a diagram constant, but that's not how it works.

Don't forget that you could use a static VI reference to your "Code VI" instead of the file name diagram constant and "open VI reference". This way the subVI will be included automatically.

[zach_listen]

Thanks for the suggestions guys!

Unfortunately, I am unable to re-build the application. The application is a deployed exe. The only thing I am able to modify is the VI which is to be called dynamically. Again, the application was built in Labview 8.5 so that means I am also restricted to using LabView 8.5 for the time being.

The thing I don't understand is why the MathScript Node keeps this example from working. If you replace the MathScript Node in the code.vi with a simple add function, the exe works. For some reason an application is unable to open a reference to a VI with a MathScript Node in it.

I'm just trying to figure out why and how to resolve this.

[GrantM]

Hello,

As you may know, MathScript is implemented on top of LabVIEW.  Consequently, there are various VIs and controls from LabVIEW's vi.lib directory that are needed for a MathScript VI to run.  A built application can run on a computer that does not have LabVIEW installed.  The LabVIEW Run-Time Engine provides support for LabVIEW's primitives, but any functionality implemented in a VI must be included in the built application.  Otherwise, the application cannot find those support VIs. 

Basically, the problem is that in trying to run your MathScript VI, you are only giving the application the top-level VI and none of the subVIs.  A way that will likely work around this is to build a source distribution with your MathScript VI.  Create a project with your VI in it.  Create a new source distribution build specification in the normal manner.  (I don't have LabVIEW 8.5 installed at the moment, but these are instructions for 8.6)  In the "Additional Exclusions" section, uncheck the "Exclude files from vi.lib" setting.  This should pull in all the subVIs you need to run the VI.  Then, open your top-level VI from your built application.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments