How can I strip hardware dependencies from an LVOOP application?

[billings11]

I've developed a lot of large labview applications in the past - espescially large test applications.  Often I've released an "office edition" of a test application.  That is, I've stripped out all the DAQmx, NI-Motion, etc. dependencies from the application and built an executable for managers to run in their offices without the hardware.  I retain all the code to save and load tests from a database, do statistical analysis, etc., but remove all the code to actually run tests.  This is so a production manager at a factory can view test results and analyze data from their office, and the IT department does not have to be burdened with the painful NI installers for DAQmx, NI-Motion, etc. that are not group policy deployable.  All they have to install is a run-time engine.  And this way I don't have to write an entirely new project... I can just strip out a couple of cases from my top-level vi's state machine (the ones that involve hardware drivers like DAQmx) and build a new executable.  Suddenly I have a version of the exe that doesn't need all those NI dependencies.

The last couple applications I developed have a large LVOOP class called "Test".  Each test type is a sub-class.  A method of each class is "Run Test".  But another method of each class is "Analyze Results".  All the hardware dependencies come from the "Run Test" method, which I never call in my office edition of the application.  But I do call teh "Analyze Results" method.  Using LVOOP (LV8.2) in this manner, even though I remove all calls to the "Run Test" method in my code, in order to run a single method of the class I have to load all methods of all inherited classes, including the unused "Run Test".  The result is that it's impossible to strip out the DAQmx or NI-Motion content easily simply by never calling it.  If it exists as part of the LVOOP class hierarchy it must load all components of all methods, regardless of whether they are being used.

Is there any way to easily structure an executable build, or remove select content from a project that will effectively eliminate the need for certain hardware driver requirements in the way I've described above?

Message Edited by billings11 on 03-04-2008 12:50 PM

[MarkBlack]

billings11,

Unforuntely there is no way to simply remove all of your hardware dependancies in an executable build. 

[Jarrod_S.]

From a high level, you have various options:

• You can reorganize your class hierarchy such that your Test classes inherit from an abstract Test class with no HW dependencies that still has the analysis routines implemented. Then the office version only needs to run this abstract Test class to view and manipulate data. The HW-specific classes inherit from this test class to get all the analysis routines, but also include their own driver calls. These child classes don't need to be shipped with the office-only version.
• You can place Conditional Disable structures around your driver calls and create a Project Symbol called Sim_Only or something. If that Project Symbol is set, you don't call any real driver functions. Then your office version can ship and run without any drivers set, but the user has to open the application from a project with the Sim_Only Project Symbol set. If they don't, they'll revert to the HW-dependent behavior. If you're building an executable out of your project, then you can build it with this Project Symbol set and the executable won't have any hardware dependency at all. The office version will work just with the run-time engine and no drivers.
  

Message Edited by Jarrod S. on 03-05-2008 04:16 PM

Message Edited by Jarrod S. on 03-05-2008 04:22 PM

[Jarrod_S.]

Cross Post

[Jarrod_S.]

P.S. I just realized that the second bullet point will be more difficult than I thought if you have things like DAQmx task controls as inputs or outputs for your subVIs. Those will be harder to disable using a Conditional Disable structure. But if you can isolate all code that calls the drivers in this manner, it should work just fine for you.

[billings11]

Jarrod,

Thanks for the response.  Did the loading of lvclasses change between 8.2 and 8.5?  I haven't tried it in 8.5, but in 8.2 if I run even one single method vi, the exe tries to load every dependency of every method vi in the entire lvoop class hierarchy.  So unless I can somehow remove all method vi's or create an entirely seperate duplicate lvclass from top to bottom it will try to load the dependencies.  I heard this may not be the case in 8.5.

I think your second suggestion would work.  I would have to actually go inside each Run Test method and disable the hardware functions there.  That way even though it will load the entire lvclass it won't look for the drivers.   Is that what you are basically suggesting?

[Jarrod_S.]

---

@billings11 wrote:

Jarrod,

Thanks for the response.  Did the loading of lvclasses change between 8.2 and 8.5?  I haven't tried it in 8.5, but in 8.2 if I run even one single method vi, the exe tries to load every dependency of every method vi in the entire lvoop class hierarchy.  So unless I can somehow remove all method vi's or create an entirely seperate duplicate lvclass from top to bottom it will try to load the dependencies.  I heard this may not be the case in 8.5.

I think your second suggestion would work.  I would have to actually go inside each Run Test method and disable the hardware functions there.  That way even though it will load the entire lvclass it won't look for the drivers.   Is that what you are basically suggesting?

---

Yes, that does sound like what I was suggesting. I don't believe there have been any noticable loading changes in LVOOP classes from 8.2 to 8.5 in terms of loading method dependencies. But you can control through reorganizing child classes or Conditional Disable structures what compiled code gets loaded. You should be able to conditionally compile a built version of your code that doesn't try to load any drivers.

[JanK]

Hi

But you can dynamically load a child class. I think that would solve your problem. If you first make sure you don't directly call any child class methods  and then you write code to dynamically load the child class. Use the "Get LV Class Default Value.vi" to dynamically launch a child class using its path. Then use it through calls to dynamic dispatch VIs.

Thanks,

Jan

Endevo

[billings11]

But I've already written, debugged, and released my application.  I just want to do something simple like deleting a few subvi's to release this "office version" with no hardware dependencies.  WIth your suggestion I'd have to go through every single vi and replace every single method call in my huge application with a dynamic call.  I'd rather shoot myself in the eye with a bolt-action pellet gun.

The real lesson is if you'll ever have hardware dependencies in just a few method vi's that need to be stripped out, you may want to forego LVOOP and use traditional LV code.  If only one or two method vi's have a couple different hardware dependencies, its the same as every single method vi having every single hardware dependency.  It may be too much work to maintain this for only a moderate benefit. 

[JanK]

I kinda assumed that you where already using dynamic dispatch since you have inheritence and the method RunTest on the child classes. The only code change would be the dynamic launch of the child class which isn't much work. But I still think I was to quick with the suggestion since I guess you would launch the specific child class for the test and thereby all the HW dependencies... So, back to square one, Jarrods suggestion with the conditional disable seems to be the best option for minimum effort.

And, yeah I agree for small apps the effort of adding lvcass structure may not give enough ROI. The conditional disable or using a (VI server) plug-in VI may be all that is needed. If more structure was need though, I would consider factoring out the HW dependencies into separate class hierarchies and use the dynamic child class launching.