PLC ladder network in LV

[MogaRaghu]

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.

[Ben]

"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

[tbob]

Even though ladder logic is crude and ancient, that is what PLCs were designed to use. In my opinion, your application would be easier to maintain if it were broken into pieces, ladder for the PLC, LV for data collection and processing. A friend of mine didn't like ladder either, so he wrote the entire application in C and just called the C program in his first ladder rung. Like yours, his program was huge. It is really up to you. Can you put up with ladder logic programming? Or would you rather put up with a very large LV program? You have to decide which would be easier to maintain in the future. If you decide on LV, modularity is the key. A very large program broken into lots of small modules is relatively easy to design and maintain. The project I am working on now has close to 1000 vi's. The main is a queued state machine that calls smaller modules. Each module calls other modules to do specific tasks. Any piece of code that is used more than once should be put in a subvi and called when necessary. This is the key to maintaining a large program. Good Luck.

[johnsold]

If there are safety or time-critical conditions in your system a PLC is appropriate as LV timing can be disrupted by the OS. Never rely on LV on a desktop computer as the only safety mechanism in your system.

There is a company offering a Hierarchical State Machine implemented in LabVIEW. I have not looked at their program, so I cannot say if it would be what you need or not, but they claim it is the next kind of state machine. Search for LabHSM.

I concur with the comments of Ben and tbob.

Lynn

[MogaRaghu]

Hi Ben,

That was a good discussion that you had put forth.

To be honest I never was and never will (?) be comfortable with State machine drawings. Maybe its a mindblock for a guy like me whose regular job is coding for automation - I have been immersed for too long in Assembly and C (for 8 bit controllers ) and VB. The transition to the LV religion was quite tough, but looks like I will make it!

OK coming back to the issue, after reading your post and other's viewpoint, I am convinced I can code the whole machine in LV. As to the time critical events, I can always synthesize them externally with one of my favourite 8-bit controllers and just pass one final digital signal for health of system. Like if the machine has some 7 safety interlocks, I can monitor them, process the states and arrive at the "health" verdict to pass on to the LV code.

And even now I have implemented a scheme for the I/Os ( both digital and analog ) like this :

1. Declare a set of Global arrays to hold the information,
- from 33 digital inputs.
- info. to write to 12 digital outputs.
- info. from 5 analog inputs
- info. to write to two analog outputs.

2. A Timed loop executing at 50ms interval in the Main.VI updates ONLY these arrays using DAQMX functions that interface with the hardware.

3. The rest of the VIs simply read-from or write-to these global arrays only, as required by the process flow. And I take care not or write/read the same array simultaneously anywhere.

4. And yes I can still manipulate one "bit" out of the 12 digital outputs. Since it is in array form, I simply use the "Replace Array Subset " function.

I do hope that the above implementation is acceptable for any size of machine. ( This in effect would closely resemble the I/O images and scan time in PLC parlance ?)

Eager to know what you think.

Regards

Raghunathan

[MogaRaghu]

Hi Bob,

That was a very encouraging post. Particularly when you said "The project I am working on now has close to 1000 vi's." !

Well that single statement settles all my doubts. My program has some 13 odd vi's which might at best reach 20. But 1000 vi's is simply LAAAAARGE.

I fully agree that an agressive conversion of repeated function blocks into sub vi's will save the day ( and sanity). Who wants a ladder when all is possible with LV 😉

Thanks for your time.

Raghunathan

[Ben]

Hi Raghunatahn,

"Eager to know what you think.
"

You said globals but did not say "action engine" or LV2 global.

Please research the use of these objects.

I normally will not use normal globals because they wind up being to hard to use properly.

Action engines give you all of the flexibility of globals but they have a lot of side benefits that lead to cleaner better performing code.

Sorry but I can not write a book this AM.

I will try to get back to this thread at a latter time.

Ben