topic Re: Large Application Structure in LabVIEW

Large Application Structure

battler. — Thu, 01 Apr 2010 23:42:34 GMT

Hi all,

I am thinking about the structure of a large application. I have built 5 independent VIs (each from independent LV Projects); 4 which gain the necessary inputs from the user (each has While Loop with Event Structure) and do their own processing to devise a large set of input data and parameters for a main processing VI. The main processing VI can be slow to function.

I was considering the following structure:

A main UI VI which calls each of the 4 UI VIs in succession using an invoke node or similar via the VI subpanels. I have never used a VI subpanel.

Passed to each of the 4 UI VIs is a large cluster which each contributes to.

The large cluster is passed to the main processing VI (which has independent While Loop) via a Queue?

Your thoughts, ideas and examples would be greatly appreciated.

Battler.

Re: Large Application Structure

andre.buurman@carya — Fri, 02 Apr 2010 11:21:56 GMT

You should research the subpanel structure (sounds very suitable in this kind of structure) and the use of Functional Globals (Labview wiki) or Action Engines to store the large cluster and have it operate on the data.

Message Edited by andre.buurman@carya on 04-02-2010 01:20 PM

Message Edited by andre.buurman@carya on 04-02-2010 01:21 PM

Re: Large Application Structure

F._Schubert — Fri, 02 Apr 2010 12:55:42 GMT

Sounds reasonable. In the LabVIEW style book by Blume there is an example of using subpanels with vi server (if I remember correctly).

You could place the Config App, App1, ... inside a state machine. This will be nice if you need to change/insert anything on that sequence (lika an abort functionality).

If your processing App might be slow, it is also reasonable to use the producer/consumer design pattern.

I think some pitfalls are in the event handling of the main window. You would need one more loop to catch events like the Panel Close? or an global Exit. Then you need to pass this event to any of the 4 Apps that might be running in the SubPanel. I would advice to use User Events for this, as the apps already have an Event Structure.

If you go OOP, there is some more concepts you might use...

Felix

Re: Large Application Structure

battler. — Fri, 02 Apr 2010 13:11:44 GMT

Thanks guys.

I'm thinking SubPanels with Producer/Consumer structure.

I can't picture how a state machine might work. Example?

Object orientated design I know nothing about.. How to learn more?

Re: Large Application Structure

andre.buurman@carya — Fri, 02 Apr 2010 13:41:20 GMT

You could have all VI's integrated in the main VI by putting it in a state-machine and have the UI's of the different VI be accesable via a tab control.

My personal favourite in this case is to use the subpanel when the configuration items have no direct relation and to use a single VI with tab control when they do.

Text below is just in case you don't know what a state-machine is.

State-machine basic explanation.

E.g. an application has 3 states:

Init (do all initialisation and auto-transition to next state "main"),

Main (do all normal application stuff, e.g. event structure for UI handling, transition to state "Clean-up" on app stop event),

Clean-up (close all references and delete temporary files).

Message Edited by andre.buurman@carya on 04-02-2010 03:41 PM

Re: Large Application Structure

battler. — Fri, 02 Apr 2010 13:46:18 GMT

Yes I've used that structure (state-machine) before, but not for such a large application. I think user events is more efficient than this, correct?

I'm thinking of adding Producer loop with processing VI. Could I use a kind of global VI for this? Can I acquire a queue from a VI not on the BD (i.e. globally) just by using the queue name?

Should I place the processing VI onto the BD?

How to pass 1 large cluster (is this the way to do it?) between applications which I'm calling via VI subpanel invoke method? Since they will only be called and won't actually be placed onto BD (or will they?), how to pass data in and out of them?

Message Edited by battler. on 04-02-2010 08:46 AM

Re: Large Application Structure

battler. — Fri, 02 Apr 2010 13:50:11 GMT

"You could have all VI's integrated in the main VI by putting it in a state-machine and have the UI's of the different VI be accesable via a tab control."

Q. How to make the UI of each VI accessible via Tab control?

My personal favourite in this case is to use the subpanel when the configuration items have no direct relation and to use a single VI with tab control when they do.

Q. I have no idea what you mean. Example? Image?

Re: Large Application Structure

andre.buurman@carya — Fri, 02 Apr 2010 14:16:29 GMT

Q. What is you idea of a large application?

"Q. How to make the UI of each VI accessible via Tab control?"

You will have to copy the frontpanel of the VI's to the pages of a tab control and integrate the code into the Vi that contains the tab control.

"Q. I have no idea what you mean. Example? Image?'

E.g. there is settings VI for DAQ, one for logging and some more. In that case I would keep them in separate VI's and integrate them as either subpanels or as dialog boxes.

The Functional Global construct is very usefull to pass data between dynamically started VI's in case of the subpanel. It is advisable though to create one functional global per data type (e.g. one for DAQ parameters, one for Path configuration, etc)

Message Edited by andre.buurman@carya on 04-02-2010 04:16 PM

Re: Large Application Structure

F._Schubert — Fri, 02 Apr 2010 14:21:44 GMT

To clarify some of my ideas, here a fast scetch:

Sorry, CCT didn't work to make a snippet.

Felix

Re: Large Application Structure

battler. — Sat, 03 Apr 2010 03:47:27 GMT

The application consists of 5 separate projects (100+ VIs each), each with a single main VI.

I am interested in the use of these "functional globals" but have never used them. How can I learn more?

I also want to dynamically call VIs. I believe I know how to do this but not sure how to best fit it into the overall structure.

Thanks for posting the screenshots.

Re: Large Application Structure

RavensFan — Sat, 03 Apr 2010 03:52:29 GMT

An excellent source for how to use functional globabls is Ben's Action Engine Nugget

Re: Large Application Structure

battler. — Sat, 03 Apr 2010 03:53:46 GMT

Schubert,

How to pass large (global?) cluster between the dynamically called VIs?

The large cluster will consist of 4 smaller clusters - 1 each for config app, app1, app2, app3. Each of the apps should fill out the data into their respective cluster.

The large cluster should be stored where? In a global buffer VI? Should it be stored in the same location as the processing VI, since this is the VI which will ultimately process the large cluster?

Re: Large Application Structure

battler. — Sat, 03 Apr 2010 03:55:23 GMT

Thanks again Raven.

Re: Large Application Structure

andre.buurman@carya — Sat, 03 Apr 2010 10:21:34 GMT

A structure to pass data between dynamically called VIs is a functional global.

There different ways to do it (queues, user events, etc), but this is the easiest to create.

I would suggest to create a functional global (action engine) per app, so you get FG_app, FG_app1, FG_app2 and FG_app3. There is no point in creating only one, since that would create dependencies between the apps (maintanability).

What is you LV version in case someone want to post an example?

Message Edited by andre.buurman@carya on 04-03-2010 12:21 PM

Re: Large Application Structure

battler. — Sat, 03 Apr 2010 11:53:11 GMT

Hi Andre,

I'm using LV 2009.

1. You mean an action engine per app? The Processing App would need data from all FG_app1, FGapp2 etc. How would that work?

2. Would the Processing app still use a queue in a Producer/Consumer arrangment? The Processing app will be slow and I want the option of a batch processor; where I queue up several configurations.

3. I do not understand what is "a wrapper VI for each type of AE call". An example of what a "wrapper VI" is would be great.

4. I have never gone about building an AE. How do I go about that?

Thanks.

Re: Large Application Structure

F._Schubert — Sat, 03 Apr 2010 12:13:08 GMT

Passing data:

Use a wire. Inside the State machine, this is via shift register. And then via queue.

Using a functinal global might lead to race conditions or a laggy behaviour if your processing loop takes long time and the user starts again with the ConfigApp.

Now concerning Action Engines. They are the poor man's Objects (but they work via vi server reference, which might be useful in your case).So you actually could go on using OOP as a 'glorfied cluster'. The main principle behind both ideas is to protect the data from unwanted modifications 'encapsulation'. In an AE, you will have a wrapper for each element to Set or Get and some extra methods. In OOP these are called accessor vi's. So when you make your cluster an object, you will use the accessor vi's instead of the bundle/undbundel function directly (inside the accessor vi, there is just this unbundel/bundle function).

What could help you at this stage is documenting the objects (even if you have clusters for now) using established methods like uml class diagrams. Ask these questions:

* Which of the data is shared among your 4 main vi's

* In detail which parts need to be accessed at which place

* Which operations need to be performed on the cluster (which would translate to methods in OOP or Actions in AEs).

I think if you can come up with a scetch of this, we can help more...

Felix

Re: Large Application Structure

battler. — Sat, 03 Apr 2010 12:29:55 GMT

Felix,

I cannot understand all this jargon without seeing example BD. Can you post some images or point me in the direction of where I can find examples.

I am interested in this OOP but I need documentation and examples. Know where to get it?

A step should be, as you say, to write down all the inputs and outputs of the 4 Apps and any dependent data between them. The processing VI will need all the data.

However, I will construct a scaled-down version of the complete architectue; the 4 Apps and Processing app will be simplified.

Thanks,

Battler.

Re: Large Application Structure

andre.buurman@carya — Sat, 03 Apr 2010 13:22:52 GMT

1. You mean an action engine per app? The Processing App would need data from all FG_app1, FGapp2 etc. How would that work?

Yes, see attached example.

2. Would the Processing app still use a queue in a Producer/Consumer arrangment? The Processing app will be slow and I want the option of a batch processor; where I queue up several configurations.

Yes, in that case a queue does what it is designed to do.

3. I do not understand what is "a wrapper VI for each type of AE call". An example of what a "wrapper VI" is would be great.

You probably don't need wrapper VI's. The AE itself is a way of data-encapsulation.

4. I have never gone about building an AE. How do I go about that?

See example and see Ben's Nugget.

Message Edited by andre.buurman@carya on 04-03-2010 03:22 PM

Re: Large Application Structure

F._Schubert — Sat, 03 Apr 2010 14:32:31 GMT

Wrapper VI's: See Andres example as a reference. I would make a wrapper vi for the Write Action which makes the Data Cluster input required. And a wrapper vi for the Read Action that won't have the input cluster on the connector pane. This isn't really code but more like 'documenting' the actions (which inputs/ouputs are valid, required ...).

Felix

Re: Large Application Structure

andre.buurman@carya — Sat, 03 Apr 2010 20:29:12 GMT

I see your point of view. Personally I don't do that in my projects (time overhead), though it make to resulting code a bit easier to understand.

When using it without wrapper for each method, you can always put a good description in the VI.documentation field.