pumprace
-
Content Count
5 -
Joined
-
Last visited
-
Well thanks Tim, Shawn, and Daklu! I rolled the model classes into a database and achieved the same functionality in a couple hours. That'll make the whole thing, well, 1000 times easier to distribute! I think I am going to try to implement the remaining ~24 classes as packed project libraries though. Thanks again!
-
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 r
-
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.
-
ps: here's a diagram of my class hierarchy
-
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 o