Jump to content

pumprace

Members
  • Posts

    5
  • Joined

  • Last visited

Posts posted by pumprace

  1. Yes it may be possible to eliminate the model classes and replace them with a database. There's actually a simple database below the model classes already that provides information on model permutations (there is an average of 5 permutations for each of the 1000 models). If it turns out that I would never need to implement a model-specific interface then I could roll those classes into the DB and make distribution of the series plugins much more manageable.

    I know I'll need to keep the series at least implemented as classes because I have to interface to different setup tools and inspection reports based on the series. So then my challenge becomes figuring out how to be certain that I won't need to build interfaces that are model-specific.

  2. Tim,

    I actually just found that document, thanks.

    The models don't change in terms of the hierarchy, but the information I need to know about them is...unknown. As we test and develop we're finding more critical peices of information that are model- or series-specific. For instance (most of our products are pumps, btw), one series has a clearance dimension between the impeller and case that is critical to performance, but this clearance isn't even a feature of most of our designs. In order to make the data useful, I have to track that clearance for each test done on that series of products. Because of this I will need to be able to reliably and easily adjust the way my application responds to different series and models, which sounded like plugins to me.

  3. 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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.