Search the Community

Hi everybody, While I was having some time to develop new scripting stuff i wondered "would it be possible to add somme scripting stuff in the VI toolbar ? " (the one with run, run-continuously, abort, police stuff and so on). My point is to add kind of a combobox that populate with every events in the current vi for a control when clicking on it. And of course show the effective event and make it blink when selecting it in the combobox. The scripting part is almost done but i now come to the real problem : "How can I add this piece of code in the VI toolbar ?" I know i can create either a Quidrop Plugin or a shortcut menu plugin but they don't fit the way i wan't to use this plugin. I asked some NI guy that told me the only options where the one above but I can't imagine that LabVIEW is not in some way developed around a "plugin architecture" so if any of you as plunge deep into LabVIEW's files and know where and how to achieve this goal it would be really nice Thank's everybody and I hope my question was clear.

I have an application where I am loading plugins from disk and executing them. Each plugin is a child class of my plugin class. I am using the factory pattern. During development, I started out by having a static plugin class object for testing purposes and then later switched to loading the plugin class default value from disk. My architecture works by dynamically launching a generic plugin handler that then loads the required plugin class and dynamically launches a method in that class. So, the handler and the plugin are disconnected from the main application. They communicate using messages. I am launching many of these plugins at the same time. A common use case would be in the 100's (this is a test system) When I switched from the static object to loading the classes, I noticed a significant slowdown, especially with higher #s of plugins (100+) loading at once. I did an experiment to make all the plugins being loaded be the same so it should only incur the disk load of the class a single time. When I compare this to the static plugin version, there is a 4x reduction in execution speed. So, it seems that the function that gets the default value of a class is much slower and more resource intensive than using a static object, even if the class is already loaded into memory. I also suspect that this function runs in the root loop, causing blocking issues. Does anyone know of a way to speed this up or mitigate the slowdown? In the past I used to cache refs of dynamically loaded plugins (before LVOOP) so I would not incur the load penalty. There does not seem to be a way to do this here that I am seeing. thanks for any ideas. -John

Hi all, My question deals with how best to distribute large collections of lvclasses that implement a 'plugin' architecture. Some background first: I've been reading the lava forum for about two years and dove head first into LVOOP about a year and a half ago. As such I may be calling what I have 'plugin' when a better term already exisits for what I'm doing; please correct me if there is a better term. The application I've got implements essentially a dynamic form that allows the user to structure properties of a tdms file with information needed to complete some kind of test on one of our products. This 'blank' file is distributed to the correct test stand where it can be used to spawn data files that are populated with information from each test run. Pretty common task I think. To implement this I have a four-tiered class hierarchy: Generic Metadata -> Generic Product Series -> Specific Series -> Specific Model The bulk of the code and all the interfaces are implemented in the first two classes with the last two providing overriding methods as needed for whatever specific product is being worked with (which is why I'm calling it a plugin architecture). This means the last two classes represent an ontology of the company's product line, which means there are a LOT of classes there. Last count I had 24 Specific Series and around 1000 Specific Models. In the development environment, I load the first two classes as constants on the block diagram then use a factory to load the specific classes from disk at run time by building a relative path off of the top level class path. This works well because all the classes are part of my project and are therefore easy to manage on disk, but I need to be able to build this application into an executable and distribute it to the entire company. How can I include the classes in my distribution and load them at run time without making maintenance a nightmare? Would packing each class and its methods into an llb, including all the llbs in an installer, and loading each class from the llb at run time work? Would my dynamic VIs work from inside llbs? Would packed project libraries be a better choice? Do I have to put the entire class hierarchy inside the library or can I compile the top two classes into the exe? Lots of questions! Also I tried to upload a diagram of my class hierarchy, but I think my webfilter is preventing me from uploading anything.