Onno

Yeah, sure. I had been considering to do that for my original post, but didn't have the time. I'll see if I can reproduce this error in a small test project. May take some time, though, so don't hold your breath ;-) Thanks a lot for your reply! Thanks a lot for your input, I appreciate it! Hm, I'm not sure I fully understand, so let me see. Do you mean: I copy "Plugin Interface.lvclass" to the directory "Plugins" (referring to my original tree picture); I let "My Plugin.lvclass" inherit from this copied "Plugin Interface.lvclass". When I create my source distribution, the paths will work out fine since the copied "Plugin Interface.lvclass" (and associated VIs) overwrite the exact same "Plugin Interface.lvclass" that is part of the Main project. Am I right? If so, I think it's a great trick. It does have a few drawbacks, though: It assumes my colleagues will go to the trouble of creating installers for their plugins. Given the hackaway nature of the work in my group (as in many small physics labs, in my experience), I doubt people will do that. I have to make copies of "Plugin Interface.lvclass". Although the Main project is in source control, this can still lead to some nasty issues, I suppose. Any other ideas that could work around this? I imagine that you could just forget about copying the duplicate "Plugin Interface.lvclass" at all, as long as you make sure the relative paths are the same?

Hi! The LabVIEW 2010 (10.0f2) project I'm working on, is a fairly big program for controlling a couple of setups in our scientific laboratory (about 500 VIs and a dozen classes — might be quite small in some people's eyes, but anyway). To make it easier for people to add their own functionality to the program without having to dig into the full project, I've decided to try and implement a plugin system. Things seem to be working pretty well, but I'd really like some advice about how I should organize my files in (sub)projects etc. I've looked around to find out what would be a good way to do this, and have ended up doing the following — which seems to be a fairly standard way of implementing this in LV: I created a "Plugin Interface" LV class, which has some basic functionality, as well as a few 'abstract method VIs' that need to be overrided by descendants. Plugins are loaded from a specific location. Each plugin is a LV class that descends from "Plugin Interface.lvclass". It implements the abstract method VIs. The main program calls the various methods of the plugin when necessary. Nothing new thus far. Let's say now that I'd like to write a plugin, without affecting the main project structure. My idea was to: Let the plugin directory be external to the main project. (E.g., main project in "D:\Dev\My Project\Main", and plugin directory in "D:\Dev\My Project\Plugins"). Let each plugin be its own project file, defining one LV class. (E.g., plugin in "D:\Dev\My Project\Plugins\My Plugin\My Plugin.lvclass", in the corresponding project "D:\Dev\My Project\My Plugin\My Plugin.lvproj"). See the following picture: Now I can keep the "Main" project under version control, separately from the various plugins. My main problems are: (1) If I want "My Plugin.lvclass" to inherit from "Plugin Interface.lvclass", I cannot do this unless I somehow add "Plugin Interface.lvclass" to "My Plugin.lvproj". (1a) If I directly add "Main\Plugin Interface.lvclass" to "My Plugin.lvproj", and then start implementing the abstract methods from "Plugin Interface.lvclass", I get the following error message as soon as I try to save a method VI: "Fatal Internal Error: "OMUDClassLinker.cpp", line 4161". (1b) Manually adding a dependency on "Plugin Interface.lvclass" to "My Plugin.lvproj", instead of the class itself, doesn't seem possible. (1c) The other method would be, I guess, to just *copy* the "Plugin Interface.lvclass" file to the "My Plugin" project. That would create a huge mess, though... And, more generally: (2) Is this a good way to organize things in the first place? Are there better ways to organize my plugin files into more or less separate packages? Would it be possible to solve this using Project Libraries? Thanks a lot for your time; I'm looking forward to hearing about your insights! Sincerely, Onno

Thanks a lot for your comments! I was vaguely aware of there being a "Show Buffer Allocations" tool, but hadn't actually ever used it yet. I'll give it a spin to see what comes out!

In a rather time-critical VI in my project, I'm doing the following: Pre-allocating an array buffer; Storing this buffer in a shift register of the loop; Using the In Place Memory Structure to update part of the buffer. This way I'm trying to prevent unnecessary copies of the array, and optimize performance. Now I'd like to put part (3) in a subVI, to clean up the BD. What I've understood (but please correct me if I'm wrong), is that calling a subVI generally creates copies of the data. This would mean that creating the subVI for (3) would defeat the whole purpose of (3). If that's correct, then my question is: can I solve this by making (3) an Inline subVI? Thanks for sharing your insights! Best regards, Onno