Implementing different "modes" in one VI

[ijustlovemath]

Hi all,

I've got a big project that currently has 3 different source trees:

1. One that's used for automatic simulation, which pulls jobs and commits results automatically from/to a database. The only visualization on the front panel is that of a progress indicator for the current simulation, and the overall simulation status

2. One that's used for simulation, and commits results to a log file. This is tailored to individual usage, and has pretty graphs and such.

3. Finally, one that's used to interface with hardware. At one point, this and the individual simulator (number two) were one and the same, but I split them to allow for leanness in the code.

My goal is now to merge all three of these functionalities into one. They all have different front panels, and somewhat different state diagrams, but the core controller is the same throughout. My current setup looks like this:

1.
2.
3.

They're largely similar, but they do have their differences (differing cluster elements in the main two clusters shown, for one). I'd just like to merge them to be able to work on them all simultaneously, rather than checking out the most current version of one from my SVN, modifying it, committing it back, and doing the same in another version.

I'm thinking of having a config file that will set a case selector, in turn initializing some function globals that allow me to cast a variant as whichever cluster is appropriate for that mode; changing the two main clusters to variants of course.

What do you think? Is this an exercise in futility? Or is there some merit to these merges that overcomes the difficulty inherent?

[yea_likethecity]

IJLM,

Am I right in thinking all you want to do is combine the three VIs into one but maintain the same functionality? If so, I think your idea to enclose them in a case and select with a variable will work fine, but as you've suggested it may not be worth the effort. Is updating the three files separately a serious inconvenience?

[ijustlovemath]

Yes and no. The simplest way would just be to have them in a case selector, but the issues pop up when a common VI (like an ODEsolver.vi) has been modified between versions such that the incoming clusters don't match, so only one of them will work for a given source tree. I suspect this could be solved better and easier with some type of OOP/dynamic swapping of VIs (polymorphic VI maybe?), although my experience with LV OOP is nonexistent.

On the surface, it isn't a huge deal to have to change out source trees, but the project is becoming so large (900+ VIs), that the time cost to save all/commit to SVN/flush dev folder/pull new tree/load new tree libs/compile new tree VIs/open the main VI is easily 3-5 min, which definitely adds up over time. I also think a big benefit of having it all under one codebase is that I could ship one application and a small configuration utility versus three separate applications.

[yea_likethecity]

"issues pop up when a common VI (like an ODEsolver.vi) has been modified between versions such that the incoming clusters don't match, so only one of them will work for a given source tree."

I don't understand what you mean by this, could you clarify? Also, do you need to commit an entire source tree whenever you commit the VI? I can understand why you would need to update the source tree so you have the latest versions of dependent VIs, but you would need to do that with a combined VI anyway. 

[ijustlovemath]

Here's the same VI in different versions. Several subtle differences + different typedefs (those two pink clusters don't have the same contents in different versions) mean that I need to check out the whole source tree to ensure no conflicts/broken arrows.

[Bob_Schor · Accepted solution]

I Object!  Is that "Class"y, or what?  If you create an Abstract Class that your various specific Data can "fit into", you can develop algorithms that work on the Class and have each of your specific Data inherit from the Abstract Class.  [I hope I said that right ...].

Bob Schor

[ijustlovemath]

I've had someone else mention the OOP approach! Do you have any references on the subject a la Core 1 and Core 2? Also, if I'm running methods on some class, how will my overall designed (state machine with events/producer consumer) change? Will things still be wired up or will I just be calling something like "self.user_input, self.initialize, self.iterate" etc via some sort of function-global-esque setup?

[Bob_Schor]

Do you have any Object-Oriented-Experience (OOE in OOP)?  I'm something of a beginner, myself, though I understand the basic ideas and have done a little LVOOP programming.  If you do a Web Search for LVOOP, you'll find a number of references to peruse, and can decide if what you are trying to do is worth the Time and Effort to learn the OO paradigm.

Bob (who also loves math) Schor

[ijustlovemath]

I've done enough to get me in trouble 🙂 Thanks for the tip though, I'll try and delve into it soon. I was hoping NI had a course on it; I watched their 1 hour LVOOP introduction (from 2009) and they referenced a podcast that went into the more advanced techniques, but I've yet to find that. Is OOP not covered on the CLD/CLA/CPI?

[Yamaeda]

OOP is not needed for CLA, just structure.

This sounds like a good candidate for an OOP approach.

/Y