programmatically choosing the dll and function within the dll

[hartzde]

I do not get that result.  Here is what I get:

[Craig_]

Please note that the examples in LabVIEW 2013 have been re-worked across the board to conform to CLD design and documentation requirements so things are organized a little differently. Try this example from the 2013 example finder.

[nathand]

Sorry, I don't know why you don't have that example available. The screenshot I posted is from LabVIEW 2012 but I checked and I do have the same example in 2013. Which version (base, full, etc) of LabVIEW do you have?

Start with the Open VI Reference function, which lets you open a reference to a VI that's either on disk (if you provide a path) or already loaded in memory (if you provide the VI name as a string). This function works in an executable as well as in the development environment, and lets you load a VI at runtime.

Alternatively, if you want to set up your plugin using objects instead of VIs, you can use the Get LV Class Default Value to load a LabVIEW class at runtime. You'll need to have a generic, parent plugin class included in your application. Use "To More Specific" class to convert the class you opened from disk to the parent plugin type, and you can then call any parent method that's configured as dynamic dispatch and it will run the dynamically loaded method.

[Norbert_B]

---

@hartzde wrote:
[...]I want similar functionality to TestStand, but I do not need all of the bells and whistles, and expense of TestStand.  This is the first automated test at this company and I just want to get it set up for expansion in the future.[...]

---

I don't want to sound like a sales guy, BUT..... you currently are designing for something "similar" to TestStand, starting to implement, test, debug, expand, maintain and deploy an application similar to TestStand.

How much time do you plan to put into this project? For all points stated above (including the time you already spent!)?

Don't you think, purchasing a ready-to-go product is taking less time for getting success?

OK, granted, you aren't done with a simple purchase... you'd have a completly new tool and should get trained on it. Which is taking time and money.

But, from my experience, considering a purchase of an already-existing tool is revealing less overall costs in most cases. The only disadvantage: Paying for a tool is explicit, paying working hours for an employee is implicit.....so costs are often not visible for re-inventing the wheel.

Norbert

PS: When using the example finder in 2013 and searching for "plugin", it does not display any "keyword". Still, pressing the enter key after typing "plugin" will result in the three examples Nathand posted as screenshot.

EDIT: Hm, interesting, the plugin example shows up, but cannot be opened. Maybe it is better to start off with online whitepapers like this one (as already pointed out in previous posts).

[nathand]

---

@Norbert_B wrote:

EDIT: Hm, interesting, the plugin example shows up, but cannot be opened. Maybe it is better to start off with online whitepapers like this one (as already pointed out in previous posts).

---

Same thing here - the example shows up in the list, but I can't open it (didn't even think to check that!). That example does open properly in 2012. Will this be filed as a bug to be fixed in future versions?

[hartzde]

Here is where I am today:

I have a program that works in the development environment but not when built into an exe.

My program takes user input and, based on that input, runs a VI from an LLB.  What I hope to do is add LLBs as needed in the future for different tests.

The error message I get from the exe program is shown below.  The part in red is what I cannot explain.  It does not exist on the input to the Open VI Reference.  The path passed in as a relative path of ELI380DCPS\ELI380DCPS.llb\CurrentTest.vi.

Possible reason(s):

LabVIEW:  File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

=========================

NI-488:  Nonexistent GPIB interface.

VI Path: C:\Users\hartzler\Documents\LabView Stuff\TesterExec\Build\

TesterExec.exe\TesterExec\ELI380DCPS\ELI380DCPS.llb\CurrentTest.vi

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.

I also do not know what the Nonexistent GPIB interface message is about since I do not have any GPIB instruments.

[nathand]

See "Why Does My Executable Not Work When Using the Current VI's Path Constant?"

Ignore the GPIB error. For historical reasons some error codes correspond to multiple possible problems, and the explanation for the error code lists all of them.

[hartzde]

I am not using the Current VIs path constant.  I am using the Application Path constant.

Also, I have an indicator on the path wire going into the Open VI Reference and the path is correct there and wrong in the error message.  So the Open VI Reference is changing the path for some reason.  The Open VI Reference Help seems to tell me that this should work, but it doesn't.

[nathand]

Could you post your code, or at least a screenshot? It might help in understanding what you're doing. I don't know of any bugs with Open VI Reference changing paths, but you could search the forum and see if anyone else has run into a similar problem.

[JÞB]

---

@hartzde wrote:

LabVIEW 2013

I have a top-level UI application, basically a test executive, from which I want to execute external VIs, the tests, that are identified at run-time.  I think that means compiling my test VIs into DLLs and then accessing the test VIs from the DLLs.  The problem I have is that I do not know how to specify the VI to the Call Library Function at run-time.

Also, since all of this is LabVIEW code, is there an easier way than using the DLLs?  Maybe an llb or packed library?  And how would I use these?

---

what you are asking for is a "Plug-in" architecture.  Your executive looks into a "List of published Tests" (put them in a PPL and use VIPM to distribute the package) and selects the "Test" vi to launch via an ACBR.  The only restriction that this involves is that each "Test" plug-in must have indentical conn panes.  Alternately, if you use a LVOOP approach, each "Test" may be a child class of the parent Test class and then the executive would instantiate the selected child class via Dynamic Dispatch,  Again, the conn panes of the child classes will have restrictions and require simillarity except for the DD terminals.

[edit]  excuse the points previously covered-  I failed to read the entire thread prior to posting.

@ Norbert,  Re: Why not TestStand?  Well the base deployment license ain't free- and the Debug Deployment license (darn near required for system repair and diagnosis) is even costlier.  We won't even mention the deployment headaches- especially for follow-on client sequences(OK, I guess I mentioned it.).  Worse, unless you are running a straight up out-of-the-box model with no customizations, you wind up with a system that is difficult to migrate prior to obsolecense unless you used a oujia board to accurately forcast the TestStand product development vision. I have run accross more than one "Universal" Test system where "Modernization" projects typically take longer than the current NI Softwre Reference Library release cycle.  That being said, TestStand has its advantages.