VERY basic - how to decide what type of architecture to use?

[MoReese]

Get used to using Virtual folders in the Project Explorer.  This will help organized your VIs into like usage.  I also mirror my file structure in the same way.  Your on the right track and asking the right questions.  The archetecture is the first thing (perhaps except the fp design) that you should be thinkig about.

[dthor]

I started of with inherited code that was first built with a "Just get the job done" mentality. This was ample use of sequence structures and case structures. It did what it was intended to do, and not much else. This has the convenience of being relatively easy to debug, because everything is linear. In fact, any new test that I'm making starts off as one long, linear VI as a proof-of-concept and a debug tool.

Starting with this inherited code, I moved to a simple state machine architecture by literally taking the ugly subVIs that were used and putting them into different states, depending on which test was to be run. Simple enough, and increased productivity by quite a bit (it used to be that each test was a different executable altogether).

From here, I continued to build on the code, keeping the same state machine + subVI architecture. The program got quite complex and powerful with this. Now that the program is doing most everything I need it to do, it's time to refactor code. I've decided to keep the simple state machine architecture, but now I've converted the tests, data analysis, probe movement, spec checking, lot/wafer/die information, and other stuff to Classes with dynamic dispatching. I don't know if this is too advanced for you right now, but it has really helped clean up the code and makes it a heck of a lot easier to add a new test.

I didn't need a producer/consumer architecture because I don't have users making any decisions before the previous one is executed. I don't need a QSM or QMH because all my processing is on short timescales and users only generate one action at a time.

TL;DR

A simple state machine is actually quite powerful and pretty easy to use and debug. It may not be as eloquent as other, but it works.

[MoReese]

Yes, the state-machine is very useful, but I use the P/C archetecture almost exclusively on every project (I'll admit, there have been simplier projects with more basic archetucture utilized).  Most, I am processing data, not events.  This is very flexible and scalable and you don't need user input to use it, with events yes, but most of my applications use some sort of external trigger to pass data to the queue whether it be from serial, file I/O, etc.  The event driven archetecture is very powerful and useful and something you should use if the operators will be accessing the front panel on a regular basis.  For most of my apps, the only people accessing the front panel are techs or myself, on rare occasions.  I do make use of state-machines, but they are part of a larger project that utilizes the P/C archetecture at the top-level.

[SnowMule]

Knowing the "right" one comes with time... do a few projects in LV, make a few mistakes (Build a project one way, then about 3/4 of the way through it realize that "hey, a queued state machine would have been a much better idea"...), learn from those mistakes, and write better code next time. 🙂

With any state machine, use a type-defined enum to control the states.  When you want to add a state and that enum's in dozens of places, you update the control once and all the controls get updated, and the case structures all match the enum... makes every step from programming to troubleshooting much simpler.

Simple state machines are a good start.  Easy to build, program, and troubleshoot.  They do have some limitations... if you need to have a responsive UI that takes data/events, and process that data that could take a while, a producer-consumer architecture is much better for that.  But for a straight-foward test with a few states, simple = better.