Call VI in EXE but have it execute in Development Environment not Run Time Engine

[jon_mcbee]

I am working on building a palette editor for distribution of a reusable code library for my company (I know the VIPM does this very well already).  I have the code complete and am trying to create an executable that I can distribute that will call the code I wrote to update/create the palette .mnu files for the reuse library, which lives on the company network.  I am using the Palette Editing VI's and it seems as though they cannot be built into an executable.  So I wrote some code to dynamically call my palette modification code (I call it the Reuse Library Manager).  When my executable calls the Reuse Library Manager dynamically I get a broken run arrow on the Reuse Library Manager front panel and the following reasons for the broken arrow:

 

It seems to me that the reason the Reuse Library Manager works when called in the development environment and not when called dynamically is because the dynamic call uses the run time engine for execution.  This made me think of how in the VIPM it opens LabVIEW while it installs packages.  If anyone knows, does the VIPM open LabVIEW in order to run the Palette Editing VI's or is it for another reason?  If it is this reason how can I force the dynamically called VI's to run in the development environment by opening LabVIEW programmatically from an executable that is running in the run time engine?

Let me know where clarification is needed.

Message Edited by jmcbee on 04-28-2009 10:00 AM

[tbd]

Hi jmcbee,

      In spite of years of using LV and building a resuable library of code, I've done very little with customizing the standard paletts, however,

Many times when deploying a new distributable I've seen a dialog like what you posted.  In most cases the problem was solved by rebuilding distributable to include the missing VIs.  In one case I added the VI-lib to the target-platform and made-sure VI-lib was in distributable's VI search-path.

There are two ways I know of to build distributables which include the VI-lib code,

1) Include all VI-lib VIs when building the distributable

 - In LV 8x, uncheck "Exclude Files from VI lib" project-property.

 - In LV 7.1 it's possible but I don't remember how! (probably a post on it around here.)

 - This can add an enormous number of un-needed VIs (see this post.) 

2) Re-write the VIs so that they are no-longer identified with VI-lib and get included "naturally".

 - Open each VI diagram, select-all, paste in new/untitled diagram.  In your case naming will be tricky, but it's doable.

 - This is a great advantage in 8x as it allows LLBs to be built with File\Save As\Create Hierarchy.

In addition, here's a tool to call following "Open VI Reference" (if it returns an error.)  This VI open all broken children making it much easier to identify specific missing parts (typically VI-lib.)

Luck/

Cheers!

[Jarrod_S.]

You should just need one extra step to call your VI dynamically in the Development Environment instead of the RTE. Before you call Open VI Reference, call Open Application Reference and specify the port your instance of the Development version of LabVIEW is using for VI Server. Also, of course, make sure VI Server is enabled.

This will require that LabVIEW is already open and waiting for you to open an Application Reference. Or you can build in a command to call LabVIEW.exe from System Exec before trying to use VI Server.

You might also need to check that your executable isn't trying to use the same port for VI Server as the development environment so there's no conflict.

[jon_mcbee]

Jarrod,

Thank you for the reply.  How do I make sure that VI Server is enabled, and how do I check what ports are being used by LabVIEW, VI Server and the executable?  This is turning into a pretty good learning experience for me.  I appreciate the help!

[jon_mcbee]

One more quick question, how do you launch a specific version of LabVIEW programmatically?