PLC ladder network in LV

Question

I have recently completed a full test rig application in LV7. Both machine control and data acquisition were done by LV. It contains some 12 different VIs which are called up by the Main.vi with hotkeys on the main panel. While most of the VIs are small and elegant, two of them namely ManualMode.vi and AutoMode.vi have grown big. Particularly the AutoMode.Vi is about 5.8Mb in size ( OK it uses all DAQMX functions for hardware interface ).
This is mainly because I am doing machine control like querying safety interlocks, responding to user commands etc. In short this would have been a breeze for a simple PLC. Whereas in LV I have created a StateMachine kind of architecture that is inside a Timed loop running at 50ms.
So even to implement a small 5 sec delay I have to initialize a counter in one state and call the next state. In that state, I subtract 1 from the counter for every call (50ms) and when counter reaches zero - do something. Now this kind of a architecture heavily depends on a Stacked Case Structure - some 75 odd cases are there and inside each case there are more such case structures.
So the net result of all this is a program that has kind of outgrown itself. My question is is this ( 5.8 Mb size of VI and 75 cases in a Case Structure )normal ? Is it better to delegate machine control to PLC and use LV only for data acquaition/ plotting / result generation ?
Has anybody done such large applications in LV ? If so how ? I am keen to know as another such machine is round the corner.
Thanks
Raghunathan
PS: Since almost all of the AutoMode.VI coding is inside a Timed Loop, breaking down each sequence segment into sub.vi's is not possible.
Raghunathan
LV2012 to Automate Hydraulic Test rigs.

Answer 1

"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
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Attachments:
State_Diagram_sections.GIF ‏45 KB