LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Running a VI as part of a project" Vs "Running separately"

What is the difference between,

- Running a VI as a part of the project , against

- Running a VI independently?

 

In both cases

- current VI path

-default directory

-application directory

are the same !

 

Problem is

If I calll a DLL (located at location Y), then my VI works well when it's within the project (location X)

If I calll a DLL (located at location Y), then my VI is not able to deal with DLL  when it's run independently (location X)

 

Please note in none of the above, I have created EXE, I am still in LabVIEW 2010 environment.

 

 

 

 

0 Kudos
Message 1 of 7
(6,343 Views)

I would have to see your code to see what where the problem lies, since the DLL does not typically need to be part of the project.

 

As far the difference goes, while the path is the same, LabVIEW treats a VI differently if it is in a project.  It actually includes the project name as part of the VI name.  This helps with cross-linking issues, and allows you to open two VIs with the same name if they are in two different projects.  I'm not sure why this affect your DLL call.  If you post your code, I might be able to spot the issue.

 

Tom Brass

Certified LabVIEW Architect

Saint Bernard Engineering, Inc.

www.saintbernardengineering.com

Tom Brass
Certified LabVIEW Architect
Choose Movement Consulting, Inc.
www.choose-mc.com
0 Kudos
Message 2 of 7
(6,331 Views)

 

Hi.

 

I do not see the difference in path, when VI is called as a part of the project Vs by-itself.

It is attached.

you may be correct in that it's the path problem...but where exactly? dn't know.

 

I stripped DLL part because they are many of them.

 

But something is different (in some path)....where

it understand the path to DLL location only when it is part of the project.

 

 

 

 

0 Kudos
Message 3 of 7
(6,321 Views)

The path is not different, it's how the VI is handled in memory.  I need to see how you are calling the DLL, as I suspect that is the problem.  You don't need to include all of the DLLs, just a single example that I can try out.

 

Thanks!

Tom Brass

Certified LabVIEW Architect

Saint Bernard Engineering, Inc.

www.saintbernardengineering.com

Tom Brass
Certified LabVIEW Architect
Choose Movement Consulting, Inc.
www.choose-mc.com
0 Kudos
Message 4 of 7
(6,312 Views)

Page 52 of the pdf is what is used to call the DLL.

The project is:TechSupportProj.lvproj.

The file is:TechSupport.vi.

 

 

To reporoduce the problem.

 

Download www.newport.com/NSTRUCT .

Apart from selected defaults, choose "CONEX-PSD" for download.

 

Replace the folder

C:\Program Files\Newport\Instrument Manager\NSTRUCT\Instruments\CONEX-PSD\ with attached ZIP.

 

Your project is:TechSupportProj.lvproj.

Your file is:TechSupport.vi.

 

First launch:

C:\Program Files\Newport\Instrument Manager\NSTRUCTServer\Bin\NSTRUCTServer.exe. This will run in the systems tray.

 

Now you connect Newport's CONEX-PSD9.

Now you are ready to replicate the problem that I see.

 

Problem:

When I call VI as a part of the project...it sees the instruments

When I call VI alone by itself, I do not see the isntruments.

 

 

 

Download All
0 Kudos
Message 5 of 7
(6,303 Views)

Looking in your code, I see that the DLL is being called using a .NET assembly.  Searching the NI website, I found this tidbit:

 

Problem:
Where should I place my .NET assemblies so LabVIEW can locate them?

Solution:
.NET requires that all assemblies either live in the GAC or in the same directory or sub-directory of the application that's using those assemblies.

LabVIEW 8.0 and later meets these requirements by looking for .NET assemblies in the following locations:

  • Global Assembly Cache (GAC) - LabVIEW can access all assemblies in the GAC.
  • Specified subdirectories - If the VI is part of a LabVIEW project, LabVIEW searches the directory that contains the project and all subdirectories of that project. If the VI is not part of a LabVIEW project, LabVIEW searches the LabVIEW.exe directory. If you are using .NET assemblies in a shared library or stand-alone application, LabVIEW searches the directory that contains the library or application and the data and bin subdirectories.
  • Relative path - LabVIEW stores the relative path to the .NET assembly inside the VI (for non-GAC assemblies) and thus LabVIEW uses this path to search as well.

As mentioned above, when your VI is in the project, it uses the project path to search for the .NET assembly.  If the VI is standalone (i.e., outside the project), it searches the LabVIEW.exe directory for the .NET assembly.

 

Hope that answers your question!

 

Tom Brass

Certified LabVIEW Architect

Saint Bernard Engineering, Inc.

www.saintbernardengineering.com

 

 

Tom Brass
Certified LabVIEW Architect
Choose Movement Consulting, Inc.
www.choose-mc.com
Message 6 of 7
(6,293 Views)

Hi TomBrass.

 

This is helpful; Thank you.

 

So If my VI is not part of the project, it will not find the .NET DLL even when it exists in the same folder !!....odd but seems accurate !

But then you must have seen, in "Involke node" LabVIEW stores from me, the path of this DLL, why does not my stand alone VI use it to find the DLL's location?

 

Thank you

 

 

 

0 Kudos
Message 7 of 7
(6,276 Views)