Leaderboard

Do we have to wait until we see it to give feedback? One thing I *hope* it does is identify what lessons people should take from the example. There appears to be a common perception that examples show the "right" way to do a particular task instead of "a" way to do the task.

For the record, when you get a chance to look at LV 2012, there's a big shipping example that I wrote included with it that is every trick I know for putting together "a full LV application", with the exception of hooking a custom Tools >> Options dialog and a custom runtime menu (gotta give you some reason for upgrading to 2013, right?). Included in that is a splash screen that loads and starts running instantly regardless of how large the VI hierarchy gets. In that, I use an animation (it's pretty simple -- just a sequence of boolean LEDs that cycle repeatedly, meant as a placeholder for more splashy graphics you might design for your app) on the splash screen that just repeats over and over while the rest of the app loads in the background. That loading is done just by setting one of the subVIs to be "Load On First Call". For most LV developers, there aren't any surprises, but I figured it was high time there was a single reference implementation that put all the interesting tricks in one place for a "generic application X". Once everyone gets a look at it, I expect a substantial amount of feedback (positive and negative, I hope) that can feedback into it for future development. I'll post more about it when LV 2012 is public.

Your question is far too broad. It's a bit like asking, "I need flexible transportation. Should I get a skateboard?" There are dozens of additional details we need to know before we can help you decide if a skateboard is a good solution for you. It could be a great solution for a teenager living in suburbia. It's a much less desirable solution if you need to do grocery shopping or had a leg amputated. In the same way there are dozens of additional details about your specific application we'd need to know about before we can suggest an architecture. 0_o listed some of them. You say you want "reusable code that can be modified for different projects." How different will the projects be? What elements will stay the same and what elements will change? Are you working in a lab environment where each project is a temporary setup and tweaking code is part of the discovery process, or a production environment where code needs to be extremely stable and software releases are significant events? The nature of your question leads me to believe you don't have a lot of experience designing software. (I see you've used Labview off and on since 98, but writing code is not the same as designing software.) I suggest your first step to creating modular (and reusable) software is to learn how to separate the user interface from the business logic. Write your application so you could replace the entire UI without breaking any of the business logic. You can use the lessons learned from that exercise to modularize the rest of your application. To answer your question more directly (but less usefully,) I would say using a standard state machine template is best if it's the best solution for your requirements. Perhaps slightly more useful advice is this: use the state machine template only if you are designing your application (or that part of your application) as a state machine. As an aside, I wouldn't consider any of the bundled templates an "architecture." They are implementation templates, not architectural templates. An architectural template would be a LV Project prepopulated with tens or hundreds of vis implementing the architecture of choice.