billings11

QUOTE(Justin Goeres @ Mar 4 2008, 03:50 PM) But here is my situation. All my hardware I/O is contained in my "Run Test" method. Even if I never call "run test", the exe is trying to load all the vi's beneath it. I've already deleted all instances where I call the "Run Test" method. But the exe still asks for all the DAQmx and NI Motion dependencies! It seems like it runs similar to the way it does in development mode - if I try to open one small method of a sub-class with no sub-vi's, it still loads 1000+ vi's from all dependencies of all methods of the entire LVOOP class hierarchy.So it seems like even if I create a method called "simulated Run Test", if "Run Test" is still present in the class hierarchy (even though I'm never calling it) it is going to try to load its dependencies. It seems like the only way to do it would be do delete the "Run Test" method entirely from the LVOOP hierarchy, or to go in each Run Test method and disable any hardware functions.So do your simulated instrument and regular instrument classes inherit from the same place? It seems like if they are part of the same class hierarchy the exe will load all the regular instrument class vi's even if you are only using your simulated instrument class.QUOTE(Aristos Queue @ Mar 4 2008, 06:55 PM) Remove the unused child class from your project tree. If it is really unreferenced, it won't load into memory. You can dynamically load the class into memory if you discover that you need that piece of hardware. This is *exactly* the behavior of the Getting Started Window in LV8.5. There's an indepth discussion of this method of programming at the Eyes on VIs blog ( and the next few posts to that blog). Aristos,Its unfortunately not a single child class, but instead a single method of all child classes.

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?

Nevermind I figured it out. My top level defaulted to stick all items in GTS.exe and I didn't realize it.

Hey Aristos, I have been studying this implementation with a lot of interest. I really love what you have been doing working to move labview in the right direction. I started with the non-AVL version just to study what you did. I think I understand how you are doing this, its very cool. When I saw all of these advanced labview techniques and new structures being used, I couldn't help but wonder if the 8.5 application builder is ready for them. I can see some of these techniques really helping me, but I get nervous about projects building before I go too far with my code. So I tried it with demo.vi in this example and the AB gave me an ambiguous error: Error 1502 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_FRAMEWORK.vi->AB_CreateNewWizard_Invoke_CORE.vi->EBUIP_CreateNewWizard_Invoke.vi->EBUIP_CreateNewWizard_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: Cannot save a bad VI without its block diagram. On the additional exclusions page or the builder I messed with the settings and figured out that if you have the "Modify project library file after removing unused members" option checked the build generates this error and no executabe gets built. If I uncheck that option the build works fine. (Apart from the annoying namespace conflict warning on every method vi, but I can live with that.) I am a little uncertain what that option even means. So this is buildable, but there is a little trick to making it build. Any ideas what content in this example would be causing this behavior? What is the AB trying to do that is causing the error?

I have a large project that makes significant use of LVOOP. It is essentially a test executive that sequences lots of different types of tests in a configurable way. I used to use a ton of variants in and out of these tests so they could be used interchangably in the archetecture of my application, but when LVOOP came out I rewrote my test executive to us an LVOOP class called "GTSTest". Then I have about 10 sub-classes that inherit from the "Test" class. Each of those sub classes are the actual specific tests. Here is a shot of the project: This is in 8.2.0. You can see I am creating a main class called "GTSTest" and that gives me polymorphism of any specific kind of test like "Torque Center.lvclass" and "AutoLinearize.lvclass". It works fantastic in the development environment. My problem now is I can't build anything with any of the LVOOP stuff into an executable. I originally added all the classes as dynamic vi's because some of them pop up their front panels. An application engineer suggested taking them out of the dynamic vi's section, but that didn't make any difference. Here is the error I am getting: TestExec Build error: Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference: Error 13 occurred at Invoke Node in ABAPI Dist read linkages.vi->ABAPI Dist Cmp Settings to Disk Hier.vi->ABAPI Get Settings From File2.vi->EBEP_Invoke_Build_Engine.vi->EBUIP_Build_Invoke.vi->EBUIP_Build_Rule_Editor.vi->EBUIP_CreateNewWizard_Invoke.vi->EBUIP_CreateNewWizard_Invoke.vi.ProxyCaller Possible reason(s): LabVIEW: File is not a resource file. ========================= NI-488: Sharable board exclusively owned. Method Name: Linker:Read Info From File O:\Software\MfgTest\Galvo Test Station (GTS)\Classes\Tests\Auto-Linearize\AutoLinearize.lvclass\AutoLinearize.ctl ------------------------------------------------------------------------------------------------------------ Autolinearize.ctl is the alphebetical first class's private data definition. So what's going on? I made all the classes dynamic and it gives me the error. I made none of the classes dynamic and it gives me the error. But actually I know I'm going to need at least some methods of all the classes dynamic because a couple of the methods get subpanelled in the program so I need the front panels. I've searched everywhere and I see no documentation at all about how to build LVOOP into an executable. But clearly you need to do something special for this to work. Can anyone help me? I have also already tried checking the "do not disconnect type definitions" box. It did not make a difference. The other strange thing is in the preview I am seeing that it does not build lvclass vi's into the exe file like normal. It is creating a new directory within the support directory named for each lvclass, then it actually puts each lvclass vi in that directory! What is going on!?