"Has anybody done such large applications in LV ? If so how ? I am keen to know as another such machine is round the corner.
"
Excellent questions! I wish I was up to the task of giving you a complete answer.
I can share some idea.
Good planning is the key to handling large applications. Since you think this next project is going ot be similar, I suggested you review the design for ways to simplify it. Not knowing the specific of the design you have in front you limits what I can do to help but I will start by offering an example that is probably about 1/3 as complex as yours, see attached image.
The attached image is the existing State Diagram (SD) of one of the VI in an application. I have defined groups of states that coupld be combined into single states that perform "higher" functions. For example the states within the red border could have been implemented as a sub-VI and called "Set-up", the green "Pre-Test", etc.
By re-writing this using "higher level" states the design would have been much easier to maintain (Note: This example was chosen because it could stand improvement!) and the number of states reduced from over 20 to about 6.
The principle patterns I look for when evaluating SD designs is the number of entry points and the number of exits. Refering back to my diagram, the read group isalways started by a transition to the "Select Cell" state. The are two departure transitions, one that is good, one that is bad. This implies (to me) a sub-VI that returns a boolean indicating exit or proceed.
The next type of pattern is single in single out. look at the "Cal Error" and "Error Ack'd" states. They can be combined into a single state.
Please review what I have to say about SD in this link
http://forums.ni.com/ni/board/message?board.id=170&message.id=112440#M112440
So then the next concideration has to be DATA. What will I have to pass into my sub-VI, what will they return. What often happens is that I find that that one set of sub-VI uses alot of the same data. Rather than carry this data around and pass it into and out of the sub-VI to do the processing or evaluation required, I start defining "action engines" that keep related data structures together and encapsulate all of the operations associated with that data. I know, I talking spacey again.
Example:
Lets say I have a DO port that is used to control an assortment of logically un-related devices. To control this port I need to know the I/O reference and the state of all of the output bit. By creating an action engine for this port I can call it from multiple locations in my code with actions like "Set bit 0" (where the previous output port state is modified by setting just the one bit) and the other output bits are un-affected. The action engines give you the ability to add a level of abstration that simplifies the calling code.
We may be able to help further if you threw together a diagram that illustrates your current design and we could offer more specific advise.
I am curious what others have to say on this subject.
Trying to help,
Ben