LVOOP class in Seattle

I'm trying to get NI to hold the LabVIEW Object-Oriented Programming System Design class in the Seattle area this fall/winter. So far, we have narrowed it down to the first half of December. But, we need a few more students to make it happen. If you are interested in taking this class, please let [email protected] know and call your Field Rep so they can coordinate things.
Here is some info on the class:
http://sine.ni.com/n...g/en/nid/205080
-John
Certified LabVIEW Architect

You can use the application builder to redirect the VI's that you were putting into an EXE into an LLB. In theory you should then be able to use the VI server to call the VI's. You will have to verify this.
First organize your plugin VI's into folders in the project tree if you have not done so already. Then, in the Build Specification:
1. In the Destination section, create a custom destination for each plugin folder. Make the sure the "Destination is LLB" box is checked.
2. In the Source File Settings section for each plugin folder check the "Set destination for all contained items" box and choose a destination created in step 1 above.
3. In the Source File Settings section for each individual VI, set the "Inclusion Type" to "Dynamic VI". Each individual VI destination should already be chosen and grayed out (set in step 2 above). Right now you have to do this for each individual VI, you cannot do it from the folder it is in. I have a tech support query into NI regarding this. For a large amount of VI's, this will be cumbersome.
Using this approach, we have been able to modularize our code into one main EXE and multiple library files. The library files contain functions, sorta like a "DLL" approach. We then have more configuration control which makes release testing easier. We do have to be careful to ensure that the same VI (such as vi.lib VI's) do not end up in multiple LLB's. This will cause VI name collisions.
I have attached an example project to illustrate this. It is a LabVOOP implementation of a timer class by reference.
Attachments:
To NI.zip ‏220 KB

Similar Messages

Nested Subpanels for LVOOP Class Hierarchy

Hi,
I am trying to figure out a way to create a configuration window for a class object using a subpanel. The problem is that I have LVOOP class hierarchy of 3 levels, and thus I want to use nested subpanels, one subpanel for each inheritance.
For example,
A.lvclass (abstract class)
Private Data Members
String A
Configuration Window VI ( Within a FP there is a String A control and a subpanel for its child class)
B.lvclass (abstract class) (child of A.lvclass)
Private Data Members
Boolean A
Boolean B
Configuration Window VI (Within the FP there is a Boolean A control and a Boolean B control, plus a subpanel for its child class)
C1.lvclass (concrete class) (child of B.lvclass)
Private Data Members
File Path A
Configuration Window VI (Within the FP there is a File Path A control)
C2.lvclass (concrete class) (child of B.lvclass)
Private Data Members
Boolean C
Configuration Window VI (Within the FP there is a Boolean C control)
What I am trying to accomplish is to create configuration windows for C1 and C2. For each configration window, there are sections for class A and class B, and for the class itself. However, I do not want to recreate the same section (for A and B) over and over again each time new children (siblings of C1) are introduced. To avoid this duplicate task, I think using nested supanes makes sense. But I don't know the best way to do it. Any advice is appreciated
Thank you
TailOfGon
Certified LabVIEW Architect 2013

See these two threads and be sure to read them thoroughly and follow the links:
http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/12623...
http://forums.ni.com/t5/LabVIEW/A-more-successful-experiment-in-creating-compositable-user/m-p/12768...
Try to take over the world!

Change LVOOP Class Icon Color on All Members

I have a LVOOP class hierarchy (LV2009) composed of several classes that when created I used the default randomly selected color for each class. For each class I have developed several member elements (VIs, Ctls, etc), and now I have decided on a color scheme I would like to adopt. Changing the color on the template icon from the class properties will allow me to propagate those changes to the class member VI icons but it does not seem to have an impact on the class control icons on each of the member VI front panels. The class data member control has the cube with the original color. I like the idea of keeping the standard cube glyph, but changing the cube color and shading pixel by pixel is not appealing.
Is there an easy way to change the color scheme of an entire class that will update the color on the VI member Icons, the data member control and all instances of the control?
Is there an easy way to change the color of the standard cube glyph that is used by default on data member controls?
Is the cube glyph in a glyph library somewhere?

Justin_P wrote:
There is not a way to associate the color of the cube glyph (class data member control icon) with the color of the class template. If I had just a couple classes I would just change them manually. If I had a whole lot of classes, I would probably draw the cube in another program (that would do the shading automatically) and turn the image into a glyph that you could use in the icon editor.
I have attached a psd file (inside the zip) that will allow you to shade any color cube for this glyph creation. Simply change the color in the "Color" layer and the shading will apply automatically. Please note, you will need to flatten all the layers before you can copy and paste this into labview.
Attachments:
lv_class_object_icon_layered.zip ‏7 KB

Lots of problems building a large executable with LVOOP classes

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:
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?
-Devin
I got 99 problems but 8.6 ain't one.

OK I figured out what is going on.
RULES FOR CREATING EXE’S WITH LVOOP
1. Do not put any lvclass or any “dynamic vi” of any lvclass in the “Dynamic vi’s and Support Files” section of the source files tab in the build window. Yes I know they are called “dynamic vi’s” in the LVOOP structure and one would assume you may need the front panels etc., but somehow they get loaded in automatically and if you explicitly include them as dynamic vi’s I think they conflict with themselves somehow. If you do this you will get the following error:
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
In this case “Autolinearize.ctl” is the first class definition in the build.
2. In the additional Exclusions section, you cannot use the “Remove as much as possible” option. This disconnects typedef definitions, and I think it is misinterpreting lvclasses and trying to disconnect the class definitions, which breaks the application. Of course, you don’t get any reasonable error message when this happens. It will give you an error 1502 as shown below:
An error occurred while building the following file:
O:\Software\MfgTest\Galvo Test Station (GTS)\GTSExecutionMenu.vi
The VI became broken during the build process. Open the Build Specification and enable debugging to include the front panel and block diagrams.
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1502 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> EBEP_Invoke_Build_Engine.vi -> EBUIP_Build_Invoke.vi -> EBUIP_Build_Rule_Editor.vi -> EBUIP_Item_OnDoProperties.vi -> EBUIP_Item_OnDoProperties.vi.ProxyCaller
Possible reason(s):
LabVIEW: Cannot save a bad VI without its block diagram.
“GTSExecutionMenu.vi” was my highest level vi that included any lvclass wires. Maybe that’s why it returned its name. Anyway what is really happening is some screw up where it breaks any vi containing any lvclass. If you enable debugging the application will work, but then if you connect to it from the development environment it will suddenly break and you can trace down and see the broken class vi’s. To fix this, the “Remove unreferenced project library members” option worked for me to keep the LVOOP intact. Of course it blows up your exe a lot bigger because you are now including every variation of every polymorphic vi instead of just the ones you are using. You shouldn’t have to do this. There is a bug in the “Remove as much as possible” option which removes LVOOP definitions that aren’t possible to remove without breaking things. I hope this helps for the next guy that tries to use LVOOP.
-Devin
I got 99 problems but 8.6 ain't one.

Lvoop class icon color

I'm confused, and think I must be missing a (simple?) detail somewhere.
I am trying to update the icons of all members of a lvoop class to a different color. Specifically, a shade of blue (in RGB = 0 - 96 - 128). However, I get a different shade of blue (in RGB = 0 - 102 - 153). I wonder the reason for this?
I've attached my example and below are the steps I followed.
Cheers,
Chris
Create new class and name ClassIconColor.lvclass
Right-click the class and Select New...VI and name the added VI ClassMember.vi
save all to disk
open ClassMember.vi and edit the icon
observed that NI_Library layer is green (R-G-B = 0-255-0) with black border (R-G-B = 0-0-0)
close VI
Open the class properties page and select Edit Icon...
observed that VI Icon layer is green (R-G-B = 0-255-0) with black border (R-G-B = 0-0-0)
Add a blue (R-G-B = 0-96-128) stripe to the banner
Click Okay to return to the class properties page
Click Okay on the class properties page and asked to apply icon changes to member VIs
Click yes
open ClassMember.vi and edit the icon
observed that the blue (R-G-B = 0-102-153) stripe to the banner has slightly different color, (R-G-B = 0-96-128) to (R-G-B = 0-102-153)

Cbl-Amo,
It is strange that the icon editor changes colors on you. I was able to reproduce the color swap following your steps and while I do not know exactly why this is happening, I have a good idea.
Something strange is that even though the Icon Editor allows for 24-bit colors, the LabVIEW Block Diagram only uses 8-bit color.
http://zone.ni.com/reference/en-XX/help/371361L-01/lvdialog/icon_editor/
My best guess is that you selected the color 0-96-128 in the Icon Editor, the closest you can get in the LabVIEW Block Diagram is 0-102-153. This is not a definitive test, but I took your class and VI which told me that they had different color stripes and dropped them both in a new VI. I took a snip of that and when I looked at it in paint, I noticed both stripes were the color 0-102-153. It's pretty silly that the Editor allows you to choose from a 24-bit color palette but that is what I think is happening.

LVOOP Class Mutation

Hi, I am just starting out with LVOOP. I've read the main knowledge-base articles, had a small amount of training (on the Advanced Architectures course) and have had a play with my own classes.
I now want to use OOP for a test system, so I created a class with lots of standard data types, DBLs, arrays of DBLs, Int32s, etc. I created a load of accessor VIs and some manipulation VIs and that was fine.
Then I decided to change the name of a member in the private data control (.ctl) from "Voltage Range" to "Voltage Spread" as this is more descriptive for me. Having used clusters many times before I expected that the bundle names would simply update automatically. This is not the case. Having done some searching it would appear that this is all about class mutation. I can see why LabVIEW would want to monitor changes to the private data control but I want all my VIs to refer to the latest version of the .ctl file.
I have had a search online about this but now I am more confused than when I started as there appears to be no simple "right-click and select Update" type command.
Any help much appreciated. By the way, I am using LabVIEW 8.5.
Certified LabVIEW Architect
Solved!
Go to Solution.

I had a very small audio class project that works. I copied it, changed a member lable and it did not ripple through. I am also seeing black lines around my object wires for no apparent reason.
From what I can read this is something to do with default values, but I cannot find out how to fix it or what the implications are.
I doubt NI would be interested in my call as I'm using 8.5 and I'm not on any form of Software Support Programme. Maybe when I have some money to my name!
Thanks for your help
Malcolm
Certified LabVIEW Architect

Programmatic save of LVOOP class default value

Hi!
I've been stuck on this littel issue for some time now, maybe I can't see the wood for trees, maybe my intention is utopic
Here is what I want to do: retrieve class default value from an existing *.lvclass (no prob so far), modify it in some sort of configuration programme and then save back the default value to this (or another) *.lvclass file.
The only intended editing is about changing the default value, not more, not less.
I have tried some VI server magic but failed (LabVIEW crashed)
Any suggestions?
Cheers
Oli
Programming languages don't create bad code, programmers create bad code....
Solved!
Go to Solution.

Well, I do understand this issues for controls, but I'm sill struggling to transfer this to the LVOOP issue.
Here's what I used to understand about loading class default values:
I'm able to load a class default value dynamically from disk as long as inheritance is set right (--> PlugIn Architecture).
So lets say I have a parent class A which has two children B1 and B2. So using the Get LV class default value.vi I'm able to load classes dynamically and cast it to class A (To More Generic Class). This way I can also load Class_B1.lvclass and Class_B2.lvclass and use dynamic dispatch.
Now, if B1 and B2 have basically the same class private data (let's say a Boolean) that only differs in default value (true/false) I have a similar case for loading as what I'd like to do for saving.
Having said that: maybe my intention should be be better described as modifying an existing class default value and save it as a new class.
I guess there is a reason why NI did not implement the saving part... just need to understand why
Oli
Programming languages don't create bad code, programmers create bad code....

LVOOP Class Versioning, saving to file

I'm storing LabVIEW objects to file. What is the best way to re-load these objects even if the class version has changed? Generally I've found that this causes few problems and the classes are able to adapt, except when I've made major changes to the class definition typedef. Is there a way to write an adapter VI that checks the class version of the stored class and up-converts appropriately?
Also, are there any good resources for general "best practices" related to LVOOP, for versioning, working as a team, etc.?

Unfortunately when loading previous classes there doesn't seem to be a way to have tight control over how old versions are converted up. The conversion (hopefully I remember the details right) depends on how they where changed within the editor, if you rename a field then the data for the old name when be placed into the new name, if you remove the field and replace it then the data for the old filed will be deleted and the new one will take the default value).
You'll want to avoid typedefs (classes should be fine) within class data, since typedefs don't maintain their mutation history.
http://lavag.org/topic/14548-class-mutation-history/
Enums can also be a problem
http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Maintain-Mutation-History-as-part-of-Enum-Type-Definit...
Hopefully some version of LabVIEW will allow more control over version mutation, but currently you would need to be very careful with the the class data. SVN (or some other file versioning system), could be helpful for backtracking if you mess up modifying the class data (just don't go before the last in use version, since that may break the mutation system).
To have to full control you would need to flatten your data manually. If you want to go that route converting things to variants then using flatten to string is a simple way of storing type data with the real data.

Determine LVOOP class name? - of a child class...

Hi,
I have a number of modules (classes) that inherit from a base class called "Module". I have these all in an array of type "Module", I would like to log some information from each of these modules, but I need to distinguish between each module.
Is there a way to determine the class name from the data wire?
I can use varient to flattened string, but I was just wondering if there was a built in property node/function for this?
Thanks,
Jonathan
Examples Attached:
Message Edited by malkier on 03-20-2009 12:39 PM
LV 8.2/8.5/8.6 - WinXP
Solved!
Go to Solution.
Attachments:
Use_Module_BD.png ‏4 KB
Modname_BD.png ‏4 KB
ArrayResults_FP.png ‏3 KB

malkier,
There is no build in function that does exactly what you are looking for, but you can use the 'Get LV Class Path' VI to return the *.lvclass path of a given object. Using this path, you can either parse out the name, or you can use VI server to get the name of the class, as shown in the attached image.
Chris M
Attachments:
GetClassName.png ‏4 KB

Is it possible to increase the timeout on the properties dialog for LVOOP classes ?

I'm working on a medium scale application which has a lot of claases in it (it's got several largish Actor Framework based modules with quite a few possible messages). Recently it's gotten to the point that when I right click on a class to bring up the properties dialog, the dialog seems to take so long figuring out my class heirarchy that it times out and gives me the attached error.
I don't suppose there's any way of increasing the time out on the dialog ? (I suspect the fact that my laptop's hard disc speed has been crippled by my IT services encrypting it isn't helping me here...)
Gavin Burnell
Condensed Matter Physics Group, University of Leeds, UK
http://www.stoner.leeds.ac.uk/

Here is the modified VI, saved in LabVIEW 2012. Follow these steps to patch your system:
1. Close LabVIEW 2012.
2. Backup the following file: LabVIEW 2012\resource\Framework\Providers\VILibrary\libFrame_OpenPageRef.vi
3. Replace it with the version attached to this post.
4. Restart LabVIEW 2012.
Now you should no longer experience the 30 second timeout when the class property page loads. I set the timeout to "-1", so it should wait as long as necessary to open the page.
Note that if you ever repair or reinstall LabVIEW 2012, you'll need to patch this file again. Also, I wouldn't try patching any version other than 2012, since there may be other changes made to this VI across LabVIEW upgrades.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
libFrame_OpenPageRef.vi ‏24 KB

Lvoop class error with built executable

I am having trouble building an executable from a fairly large application in LabVIEW 2012. The application runs fine in the development environment. The project uses about 50 classes and several hundred sub-VIs. I had some initial problems with build error 1502 (cannot save a bad VI without its block diagram), but after enabling debugging I am able to successfully build the EXE. However, when I run it, a small dialog pops up before any front panels are opened:
LabVIEW: Generic File I/O Error.
The file "Hardware Detector.lvclass" could not be loaded.
After hitting OK, my splash screen opens up with a broken arrow, and another dialog reads
VI has an error of type E208. The full development version of LabVIEW is required to fix the errors.
This is one of the classes used in the project. Based on advice I've seen other posts, I've tried a few things:
Unchecking all boxes under Additional Exclusions (don't disconnect typedefs, don't remove extra files, don't disconnect inline subvis, ...)
Adding the class folder to the Always Included list under source files (actually its grandparent folder)
None of these seemed to make a difference. The only things I can think of that are unique about this class are that 1) it resides under a fairly deep folder hierarchy (five folders below root) and it makes use of the Set/Unset Busy Cursor VIs. I don't know if any of that matters.
Any ideas?

PackersFan wrote:
Are you dynamically loading this class?
If you go to the Source File Settings sections, what is the destination for this class?
Are you using the 8.x file layout?
You said you enabled debugging. Can you connect to the EXE with a debugging session and check out the block diagrams? Sometimes in my experience I found that those errors could be a bit misleading.
By dynamic loading I assume you mean loading the class from a path instead of dropping a constant on the BD. No, I am not.
Destination is the executable.
No 8.x layout
I can connect, but still get the same Generic File IO error. Error list gives no errors. I can open the splash screen block diagram, but once I started trying to open subVIs on the block diagram, LabVIEW crashed. I might mess with this some more.
Norbert_B wrote:
Adding some questions:
Are all sources (classes and subVIs) implemented in the same LV version?
Did you masscompile the whole project before building the EXE? If so, did you get any "bad VI" reports?
I initially started the project in LV2011, but migrated to LV2012 recently. Never tried a build in 2011, but the class that seems to be creating the problem was written in 2012.
On your suggestion I tried a mass compile. No bad VIs in the main code, but there were a few in a "test panels" folder in the project. None of these VIs are called by the main code, but for good measure I removed the folder from project and re-built. Same problem.
I did not realize application building was so fragile! Thanks everyone for your help so far.

LVOOP class Singleton implementation

Hello all,
I am trying to implement a 'Singleton' class because I want multiple threads to be able to access the class data.
I do have a scalablity concern regarding the class data. Currently,
the class data control (cluster) has four array elements. I plan to
use one private (write) method .vi for each data element since I don't
want to have to update all four arrays. If I want to added other
controls (numeric, boolean, array, etc.) to the class data control, I
will have to create additional write methods and (at least) modify the
read method.
Is there an easier way to scale this data?
I'm using LabVIEW 8.20.
Regards,
Mark
"There is a God shaped vacuum in the heart of every man which cannot be filled by any created thing, but only by God, the Creator, made known through Jesus." - Blaise Pascal

One new feature of LV8.5 was the ability to automatically create accessors for private class data, saving you time for a normally tedious task.
And if you implement a Singleton pattern along the lines of the Discussion Forum post I mentioned, adding data accessors is no more difficult for the by reference case than it is for the by value case.
Are all the arrays in your cluster the same type? If so, you could make your data a little more dynamic to facilitate on flexible accessor VI instead of one for each array. For instance, instead of a cluster of four arrays, you could have one 2D array, where each row represents one of the arrays. Then your accessor takes in the array index to get, and retrieves that row from the 2D array.
The downside there is that all of the rows have to be the same length, so the shorter arrays will get padded. To get around that, you could have an extra array in your private data that denotes length, with one element for each row. Then you take a subset of the array when passing it out. Or you could have a 1D array of clusters that contain one array in them. Then the arrays in the clusters don't have to be the same length as each other. This is a common way to handle this situation in LabVIEW in general.
Jarrod S.
National Instruments

Constant wait cursor when editing with LVOOP

I've searched around several times for any mention of this problem but have never found anything. It continues to drive me crazy so I figure I'd ask about it.
I have a decently sized project utilizing about 25 LVOOP classes in the hierarchy. Whenever I edit a VI within a class, every change I make causes a wait cursor for about a second or 2. This is not a long time, but when I'm in the middle of making something and trying to edit a VI rapidly, it gets extremely annoying to be blocked every couple seconds as I place, move, and wire objects.
I assume this has to do with compiling the VI, any callers, and doing something with the class, but is it common to block input while this takes place? Is there any remedy for this?
I'm developing on a 1 yr old Xeon system with a 10k rpm drive and 12GB of ram, it's definitely not an issue with my computer being slow.
Thanks

I am working on a large LVOOP project with 30 lvclasses. The only time I get the wait cursor is when I edit the type defs and select Apply Changes. I do not notice any delays when editing the VI's whether they are methods or plain old utilities.
In my hierarchy, I created inheritance by having lvlibs which also contain lvclasses. Most methods now access the superclass (well, that's what I call it.. the cluster that contains all classes).
Do you have access to another PC which has LV installed? If so, do you get the same behavior?

Including External LVOOP Public Methods in Executable

Hello,
I have an application which on the top level must 'talk' to several different instruments; a LabJack UE9 (USB) , a Newport Motion Controller (USB-Serial), etc.    When I wrote the drivers for these instruments in LV, I used the LVOOP functionality and created individual Classes with public methods for each of the different devices I need to communicate with. Sounds logical to me, anyway.
In my top-level application, I call the public methods (and must include local instances of the LVOOP classes) for those independant instrument-specific classes. In the development mode, everything works peachy.   However, when I go to build the application executable (build), I get some weird behavior;
Firstly, with the default setting in 'Additional Exclusions' in the Build Properties of 'Remove as much as possible', I get errors when the builder gets to my independent classes. I get the message:
"An error occurred while building the following file:
C:\Documents and Settings\Wes Ramm\My Documents\Projects\RDT\LabJack\Class\Common Methods\Get DO Line State.vi
The VI became broken after disconnecting type definitions. Open the Build Specification and choose a different option on the Additional Exclusions page."
Ok, it seems that the class object is not linking, but I can get around that by selecting the second option in 'Additional Exclusions' ; 'Remove unreferenced project library members'. BUT, when the build is done, I get a couple of subdirectories with vi's named for all the different class methods for each independent that I am calling. There is no front panel or block diagram for the vis, so it looks like they are correctly 'included' in the build, but it seems cumbersome to include these subdirectories.
I even tried to 'add' the independant classes to the project by 'Add Folder', but got the same behavior.
The classes that I made are not a part of the top level VI, and the top Leve VI is not a member of any of the classes, so this I think is the crux of the matter. However, I am instantiating only the public methods, and the problems only pop up when I try to build the executable.
Am I missing something? Is there a more elegant way to do this? Any advise / tutorials / knowledgebase articles you can point me to?
The tree for the directory structure for my build looks like this (for reference)
\\Application Directory\
                         Executable
                         \Config
                                  \ Class One.lvclass (first external class that I am calling in my top-level vi)
                                      \ Method 1
                                      \ Method 2
                                      \ Method 3
                                     \ etc
                                  \ Class Two.lvclass
                                        \Method 1
                                        \Method 2
                                        \Method 3
                                        \ etc
Thanks,
Wes Ramm
Wes Ramm, Cyth UK
CLD, CPLI

Hello Wes Ramm,
It's better late than never! Hence I'm going to address some of the issues that you've brought up.
1) Which version of LabVIEW are you using? LabVIEW 8.5 has fixed a lot of issues that occured between the Application Builder and LV Classes. If you were using LV 8.2, I would suggest changing to LV 8.5 or at least LV 8.2.1
2) Apart from setting "Do not disconnect type definitions or remove unreferenced members" in the Additional Exclusions page, I would suggest also checking the box against "Enable Debugging" on the Advanced Page.
The following forum post has discussed many of the problems that have come up when building an executable which uses LVOOP classes. Hope this helps.

LabVIEW 8.2 classes do not work in LV 8.5?

I just switched to LabView 8.5 to take advantage of the new features in the Project Explorer.
Unfortunately the conversion of my project from 8.2 to 8.5 seems to have completely destroyed all of my LVOOP classes in the project.
Everthing was working fine right after I opened the project, however, after saving all the VIs in the project, the next time I opened the project all class files showed up as "(not loaded)".
When I right clicked on them and selected "load" some of them would load, some of them would do nothing, and some of them would crash LabView (The last time you ran LabVIEW, an internal error or crash occurred at TDUtility.cpp, line 1524.).
When I double clicked on the class datat type control in the "not loaded" classes, some of them would search on disk for a file with the name of the control (although I thought the control is embedded in the lvclass file) and others would crash LabView (The last time you ran LabVIEW, an internal error or crash occurred at ctrledit.cpp, line 614.)
And when I try to save my project into a different folder (duplicating everything) I get a requester saying that xxx.lvclass is not a valid LabView file.
Did anyone else run into these problems? Any idea how to fix them?
Any help would be appreciated.
Cheers,
Heiko Fettig

Well, with some help of the guys at LAVA I found the root cause of the problem and a work around.
It looks like the problem only appears when converting from 8.2.1 to 8.5 and only if there is a 'resource control' in the data type of the class, e.g. VISA control, DAQ channel control, DAQmx task control, etc.
For some reason in this case it seems that the class is updated to 8.5 but the containing data type is not or something along those lines causing the class file to become corrupted.
The workaround is this:
Open the project in 8.5
Before saving or mass compiling do the following:
Open every class data type that contains a resource control and slightly change the physical dimensions of the resource control. You can change it right back as well (although not by using undo ;-)
If the resource control is contained in a cluster or typedef, you need to only change the dimensions of the cluster or instance of the cluster.
This seems to flag the class for proper update.
Mass compile the project
Close the project
Here are the links to the two LAVA threads I found on this topic:
http://forums.lavag.org/85-LVOOP-Upgrade-Problem-t8795.html
http://forums.lavag.org/Problem-with-conversion-of-LV-82-classes-to-LV-85-t8847.html
I hope this will be fixed since I don't think I am the only one using resource controls in class data types.
Cheers,
Heiko

LVOOP class in Seattle

Similar Messages

Maybe you are looking for