Leaderboard

No, you are not misusing libraries as far as I can tell and the "problem" you are seeing is one of the reasons I use them. In short, you have discovered an error in your design. When building an application you have to be aware of the dependencies you are creating between components. Currently your low level components are statically dependent on higher level components. Sometimes that is useful (such as when implementing a HAL or plug-in frameworks) but a reasonable rule of thumb to start with is, "let high level components depend on low level components, but not the oher way around." Grab a piece of paper and draw a rectangle for each component in your app. Next draw arrows from each component to every other component that it statically depends on. This is your dependency map. Do you see any cycles? (My guess is you'll find several.) You'll want to change your code to break those cycles. That's why you aren't able to load a single library without loading the whole application.

When I'm feeling particularly snarky I call it Error ID: 10T. ("Idiot") (I haven't yet built that error into an application... maybe someday...)

I also tend to think of a piece of data existing independent of any given vi, so from that perspective I agree with you. However, I'm not sure that's necessarily the correct way to think about it. As I understand it, each vi is allocated its own data space in memory. No other vi has permission to edit that data space. When a parent vi passes data into a sub vi, the sub vi's data space gets its own, independent, copy of the data.** The "name" of that data space is defined by the wire name, which in turn is defined by the terminal name. In other words, there is no independent "name" attribute for individual pieces of data (unless you explicitly add one,) only names of data spaces. So while part of me thinks it would be more clear to call it Get Terminal Name, doing so also kind of obscures the underlying nature of dataflow. (**Yes, we know compiler optimizations often are able to eliminate unnecessary data copies so strictly speaking it might not be true. But it's still useful to think about it that way.)

Hmm. So are you saying it is data tracking rather than interfacing (like different comms interfaces, different functions etc)? Maybe a DB would be a better way forward and could simplify your heirarchy to series 1,2,3 etc.

Dependency management has not been discussed much on LAVA or in any of the NI material I've seen. Understanding its importance was one of those "Aha!" moments for me. Now creating a component dependency map is one of the very first architectural tasks I do, both on new projects and when taking over an existing code base. The VI Hierarchy window has the ability to collapse a library down to a single icon. That can be very useful for figuring out your dependencies in an existing project. I don't have an easy "one size fits all" fix for breaking dependency cycles. The best solution depends on many project-specific considerations. However, here is an (incomplete) list of general guidelines... 1. Avoid dependency cycles. (I know I said it before, but IMO it ranks pretty high on the "rules not to break" list.) 2. Reuse components should *never* depend on application-specific components. Ideally reusable components have no other dependencies, though occasionally it may depend on another reusable component. 3. The dependency map doesn't need to be a tree. In other words, it's okay for 2 or more higher level components to depend on the same low level component. 4. Custom data types, such as classes and typedefs, tend to create lots of dependency links as the data is passed around the application. Off the top of my head here are three ways to work around that: 4a. Create a low-level, app-specific library for your custom data types and have all your non-reuse components depend on that. 4b. Use Labview's native data types to exchange information. A 2d string array makes a great lookup table for passing arbitrary information. (Note: Often using native types to exchange information increases the opportunities for runtime errors. It takes diligence to ensure you are adequately testing those possibilities.) 4c. Use "adapters" to convert from one data type to another. This can be especially useful when your reuse component communicates in generic or custom data types and you want to use a different, application specific data type. [Note: In this thread, when I use the word "dependency," I am referring only to static, or compile-time, dependencies. Other types of dependencies include dynamic dependencies (depending on a dynamically loaded vi via path information) and definition dependencies (depending on a schema, protocol, or other definition not explicitly defined by code.) Managing those dependencies is important but beyond the scope of what I am discussing here.] --------------------- [Edit - It will be well worth your time to learn about dependency injection. Don't know how I managed to forget mentioning that...]

I'm not clear on what you're doing from your description. If you have a static list of models that never changes then why not include the classes in the executable? Otherwise, have you looked at https://decibel.ni.com/content/docs/DOC-19176 ? Tim

Protohuman instantiation complete! Just cross-posting the birth announcement of our daughter on the NI Breakpoint forum! (Higher res photo at the link above)

Sometimes when I need to search through cluster arrays with some element values excluded, I do like this Download File:post-5958-1206627103.vi 1. Turn cluster array into a boolean cluster array by checking equality 2. Filter the active element by performing an AND operation 3. Search for the desired boolean cluster pattern In this case the resulting index is 4, since the first element wasn't activated. Hope this helps. /J