Large Application Structure

[battler.]

Please provide an example of AE with wrapper VI.  I really want to understand to be able to implement wrapper VIs.

I am trying to plan well so that I can have robust and maintainable (easy to understand) code.

Today I will create a scaled-down version of the Project in order to develop an application structure.

[battler.]

Hi all,

Thanks for your help thusfar.

I have created a Project (file attached) which I want to use to prototype the structure of the application.

As per advice, I have created an AE for each ConfigApp, App1 and App2.  I haven't produced the Processing App but that needs to be included in a Producer/Consumer arrangment (separate loop).

Please have a look, arrange as needed and repost.

I will continue to work on it and add your suggestions.

Battler.

[F._Schubert]

Some basics of the event structure:

* Place the terminals of the buttons inside the corresponding events and set the action to latched. They snap back the moment you read the value from the terminal (no wire is needed!).

* Remove the timeout frame

* Create a Frame for the Done Value change event, place the stop button in there and wire it to the while loop stop (use default if unwired for the tunnel). This allows you to create a Panel Close? Event that stops the loop as well (but configure a new frame for it to discard the event).

Forthermore the Run VIs Invoke nodes should not be necessary.

Felix

[battler.]

Felix,

I removed the Run VIs invoke node and applied your other suggestions.

The problem is that when I press a button to show VI in subpanel my main VI freezes and I can't interact with it.

What is wrong with the following?

Also, should the VI reference be strictly typed like this?  How will this work in an exe?  Is there a better way to do it?

[F._Schubert]

The freezing behaviour makes sense. I'm not sure if the Run methode resolves this issue correctly, you will need to check if it works (also thing about users clicking on the same button twice).

If you look back at the code I posted on page 1, I would decouple the event handling of the main window from the state machine handling the SubPanel.

Your code now allows the user to start any of the 4 Apps by a button, not limited to the sequence of your inital post. If this behaviour is now desired, my draft has to be modified (e.g. use a queue to set the states in addition to the user event to exit a state).

Felix

[battler.]

The user should follow the sequence but should have the option to return and change settings at any of them.

I don't know which method to use to call the VIs (apps).  Should I use the Call by Reference node or the Invoke method (shown below taken from an example VI I have)??

"use a queue to set the states in addition to the user event to exit a state" - can you elaborate?

[F._Schubert]

There is many ways to code it. From your last post, of course you can do it this way as well. As long as the Main VIs update some (hidden) indicator, you can also use the GetValue methode to get the data for the Processing App instead of the functional globals.

Here a short draft of how you can make a very scalable plugin architecture.

I know to less of your app to give you more detailed advice. Things to consider: how do the 4 Apps depend on each other?

-> Shared recources such as Instruments? Can they Run in parallel? Do you need to lock recources for data aquisistion?

-> Dependency of data, Is App3 affected if you change something in App1? Do you need to enforce a re-run?

-> How will your final data processing be dependend on all 4 Apps, can you process if one hasn't run?

-> Should it be possible to run an App without the Main (maybe useful for debugging)?

But also:

-> What kind of GUI are your users expecting/familiar with? Tabs? Multiple Windows? ComboBox? Window Menu?

Concerning executables: I don't know how easy it is with new versions (I think the LV project helps). It isn't as easy as clicking the 'Build' button in LV 7.1., but I always did get such things running. Try to do a build with some dummy code that just uses the things we were/are discussing here.

Concerning Queued state machines: There is some current discussion where the OP has posted some very simple code demonstrating it:

Felix

[battler.]

---

F. Schubert wrote:

-> Shared recources such as Instruments? Can they Run in parallel? Do you need to lock recources for data aquisistion?

---

 There is no hardwarde or other external processes involved with this project.

---

-> Dependency of data, Is App3 affected if you change something in App1? Do you need to enforce a re-run?

---

Yes, any ideas? 

---

-> How will your final data processing be dependend on all 4 Apps, can you process if one hasn't run?

---

They all need to be run. 

[battler.]

I have read Dr Damiens post about "using" sub panels.  He uses OOP in his implementation:

http://forums.ni.com/ni/board/message?board.id=170&message.id=445243&jump=true 

I am wondering whether I should take the OOP path.  This is a quoted from NI:

4. Who should use LabVIEW object-oriented programming?

• VIs to be maintained for a long time
• Large application
• Multiple developers working on same VIs

The first two points apply to my application..

[F._Schubert]

On your Q's two points above: I would simply enforce the user to run step-by-step by disabling all but the n+1 option after each run. (Example: If App1 is finished, enable ConfigApp, App1 and App2, disable App3).

On the OOP aproach, if you have enough time (for me this is a big constraint), go to learn LVOOP! The big difference between LVOOP and the flavours of OOP you find in most other languages is, the natural implementation in LV is by-value and not by-reference (those nasty pointers...), although there are several ways to do by-ref in LV as well.

Going OOP, I think there is a brilliant introduction on Expressionflow.

As suggested by Damien, it would be nice if you would 'blog' your learning LVOOP on the forum. Not only will you attract the attention of centuries of experience willing to help/discuss with you, but you would also generate a valueable ressource for the community on 'how to start with LVOOP'. For sure you'll get a lot of kudos as a reward.

Felix