LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

open via reference in executable

Hello all

 

in my project i call a sub vi with open vi reference .

 

Capture.PNG

 

when i see the path it's right.

but i get this error :

 

Open VI Reference in main.vi<APPEND>
VI Path: <b>E:\electronic\project\abdipor\Tinsile Pc Software\94-5-24\build\Application.exe\loadReaport.vi</b>

Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.

LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.

 

 

0 Kudos
Message 1 of 16
(6,005 Views)

I can't describe why (other than the LV RT explanation in the error description - perhaps because your VI calls other VIs and it can't find/access them from inside the executable or it has something to do with being unable to read files by path from inside the executable), but I don't think you can do this.

 

Use a Static VI reference (with the path property) instead. This will work both in the development environment and in an executable (and will automatically include the VI in your executable).

 

(Maybe if you specify the VI by name rather than path it can find it in memory from the executable?)

 

If your VI is included in the executable, then why are you calling it by VI Server (or an asynchronous call by reference) rather than just putting the SubVI on your block diagram?

 

 


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 16
(5,995 Views)

Did you actually include that VI in your executable?  Since you are dynamically calling it, the build spec cannot automatically include it.  You have to explicitly tell it to "Always Include" that VI.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 16
(5,984 Views)

I just wrote a little test routine (attached) that mimics what I do when I need to run a VI "detached".  Like Sam, I use a Static VI Reference to the routine that I want to run.  When I create the Reference, I make it a Strictly-Typed Reference  (a Right-Click option), as I need to wire the Type into the top of the Open VI Reference (you'll see why in a minute).  I drop a Property Node and wire the Reference in and choose VI Name (not Path), which I wire to the VI Path input of Open VI Reference (it accepts both).  I then wire 0x80 into the Options input, as I'm about to use Start Asynchronous Call, and want to use Call and Forget.  I then drop a Start Asynchronous Call function, wire the VI Reference to its input, and then wire any input parameters that the called function needs.

 

My demo had a VI running as a Modal Dialog that had a Stop button (which obviously stopped it).  It was called with a reference to a Boolean Control that was used to return the value of the Stop button (always True, obviously) from the Dialog box.  In my demo, I called it directly, and then called it using the method I just described above.  It worked just fine.

 

I then built an executable.  The only VI I needed to include in the Executable was the top level VI, the "Start-up" VI.  I didn't need to do anything special with the Remote Stop (detached) VI, as it was automatically included by having a Static VI Reference in the mix.  Needless to say, the executable also worked perfectly.

 

Bob Schor

0 Kudos
Message 4 of 16
(5,970 Views)

thanks for your reply

 

 

"Use a Static VI reference (with the path property) instead. This will work both in the development environment and in an executable (and will automatically include the VI in your executable)."

 

I tested with static Vi reference it works fine but because of absolute path if change my project path Then what will happen ?

 

"f your VI is included in the executable, then why are you calling it by VI Server (or an asynchronous call by reference) rather than just putting the SubVI on your block diagram?"

 

because i need them to run simultaneously .

 

"Did you actually include that VI in your executable? Since you are dynamically calling it, the build spec cannot automatically include it. You have to explicitly tell it to "Always Include" that VI."

 

Yes i have don it.

 

 

 

"I just wrote a little test routine (attached) that mimics what I do when I need to run a VI "detached".  Like Sam, I use a Static VI Reference to the routine that I want to run.  When I create the Reference, I make it a Strictly-Typed Reference  (a Right-Click option), as I need to wire the Type into the top of the Open VI Reference (you'll see why in a minute).  I drop a Property Node and wire the Reference in and choose VI Name (not Path), which I wire to the VI Path input of Open VI Reference (it accepts both).  I then wire 0x80 into the Options input, as I'm about to use Start Asynchronous Call, and want to use Call and Forget.  I then drop a Start Asynchronous Call function, wire the VI Reference to its input, and then wire any input parameters that the called function needs."

 

 

here again the path is absolute .

 

and as i see the main diference between "start Asynchronous " and "Run Vi " propery node is just terminal that we have in "Start Asynchronous "

 

0 Kudos
Message 5 of 16
(5,936 Views)

Are you sure you named the VI correctly?

 

Your code is calling loadReaport.vi which seems to be mispelled to me.  Did you actually name the VI with the correct spelling of loadReport.vi ?

0 Kudos
Message 6 of 16
(5,930 Views)

yes i do .

that's because of my poor english .

htere are several call like this in my project non of them works .

 

0 Kudos
Message 7 of 16
(5,924 Views)

If you want to run a VI simultaneously, just put it on the block diagram:

2015-08-27_11-54-51.png

 

The only main reasons to use Run VI or ACBR (call by reference) are either:

1) You want to call the VI dynamically, e.g. if you don't know which VI you want to run until run-time or to load it only when needed

2) You need to launch/run multiple instances of the same VI (perhaps at different times)

 

The Static VI reference will ALWAYS point to the correct VI path...whether it is inside an executable or in the development environment. If you move the project it doesn't matter, LabVIEW uses relative paths for most things (and every subVI should be on the same level or a sub-folder of the LabVIEW project file).


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 8 of 16
(5,906 Views)

I know this thread is old but it accurately describe my problem. As specified by Sam_Sharp,  using Static VI reference (with the path property); The vi linked to the static reference will not open in executable because the returned path is obiviouly wrong. Return path is something like application.exe\vi name.vi. Does any one know the best way that will work in  development and  in executable? Thanks.

 

0 Kudos
Message 9 of 16
(5,558 Views)

Can you post the non-working code so we can see it?

 

Because it should work as described:

Run by reference.png

 

If you do that, the "Path" output will be a disk reference in the IDE such as "C:\LabVIEW Code\blinkenlights.vi", but when you compile it, it comes out as a VI inside of the EXE such as "C:\Application\App.exe\blinkenlights.vi".

 

Wiring either of those into the "Open VI" node should work.  If that doesn't work, can you tell us the error number and text that come out of the "Open VI" node?

0 Kudos
Message 10 of 16
(5,548 Views)