Large Application Structure

[RavensFan]

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

[battler.]

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?

[battler.]

Thanks again Raven.

[andre.buurman@carya]

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

[battler.]

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.

[F._Schubert]

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

[battler.]

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.

[andre.buurman@carya]

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

[F._Schubert]

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

[andre.buurman@carya]

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.