Fundamental questions before starting next project

[labview_beginner]

Last project I put together received scathing criticism - and I have to say that I did not put any effort at all to clean the code up or optimize it. The reason is I started with small projects and within couple of months it just grew out of hand with requirements matrix gradually increasing.

So this time around I want to take advice from you guys on architecture issues before I jump into programming. The two fundamental questions:

1) I always thought that SubVi is like a method in C++. If I need to use that code multiple times, then I better put it in a SubVi. But after going through some of the posts on this forum it seems that people use SubVis to reduce # of wires,blocks,etc. on the main Vi too. Is this a standard practice?

2) If I want to have more than 1 VI in the software, what is the best way to send data from one VI to the other VI? SubVI has input and output wires. So it is easy. But VIs do not. Basically I want to have Main VI where I get all the information from the use through a front panel and then go off doing my data acquisition. I want to keep the Main VI as clean as possible. There will be some operations which will need only 1 input and will have only 1 output. But this operation will be used only once in the who operation. So can I have this operation all in a VI and then call it in the Main VI?

3) If I have 3 different VIs in my application, and I define something (say an array) in the Main VI or for that matter second_VI.vi in my application, will that be available in the third_VI.vi ?

Thanks in advance.

[labview_beginner]

Simple example in the attached VI. All the code which sets current on 4 of the current sources needs only 1 input from the user - how much current. Everything else (like the VISA I/O instrument, etc) need not be in the main VI (Front Panel). And this is just 1 example.

All I want to have in the front panel is various drop down input fields for the user to select and hit the "collect data" button. Everything else needs to be transparent. I do not want a bunch of long wires in the main VI (front panel. vi).

Ignore the bundle/unbundle icons. I just wanted to see how the bundle/unbundle thing works sinceI have not used it before.

How can I put the whole of "set current" code in another VI and call is when I have the "input current" from teh user from the front panel?

Thanks in advance.

[Drewski]

The LabVIEW software has Frameworks templets you can use as a start for a better organized large application.  You may want to look at the "standard state machine" example and/or "Queued Message Handler" as bases.  As for passing an array around, you can have an array as an indicator to pass out of a vi or as a control to pass into a vi.

As for how and when to use sub-vi's there are probably as many opinions as programmers.  I suggest you develop a style that works for you.  Until you develop your own style I suggest you use sub-vi's to limit the size of the code on the screen to two horizontal screens, scrolling left to right.

When you make a subvi, put inputs on the left and outputs on the right.  The tutorial also has a small section on style... Under Fundamentals -> Development Guidelines -> Concepts -> LabVIEW Style Checklist.  There are other sections you might want to read as well, Development Models.  You can decide how much information you want to read before you start on a large program.

One way to help flesh out the feature matrix (your words) would be to do "use cases" where you write down all the actions and buttons the software would provide for all the different uses cases.  For example at an ATM machine, one use case would be checking balance.  User inserts card, enters password, presses check balance button, chooses savings or checkings, chooses balance printed to screen or printed on receipt, balance printed to screen, card is returned.   There are lots more use cases, withdrawing funds, depositing funds.

Good Luck 

Message Edited by Drewski on 11-14-2008 01:23 PM

[Britoa]

---

Drewski wrote:

As for how and when to use sub-vi's there are probably as many opinions as programmers.  I suggest you develop a style that works for you.  Until you develop your own style I suggest you use sub-vi's to limit the size of the code on the screen to two horizontal screens, scrolling left to right.

---

I agree with most everything you said, except the scrolling part.  I hate to make code that makes me scroll.  I understand sometimes, when your init block is just off to the side, and your exit block is on the other side, it gets close, but anything more than that and it's too hard to follow.  As for sub-vis, I go by the rule of thumb that if it takes more than one or two lines to describe base functionality, it should be split into sub-vis. 

[RavensFan]

---

labview_beginner wrote:

1) I always thought that SubVi is like a method in C++. If I need to use that code multiple times, then I better put it in a SubVi. But after going through some of the posts on this forum it seems that people use SubVis to reduce # of wires,blocks,etc. on the main Vi too. Is this a standard practice?

You could call it similar to a method.  I would say a subroutine or function is a better terminology since the term method is more applicable to object oriented based programming.  Basically any way to encapsulate a portion of code, particularly if you use it over and over.  It might have input and/or outputs, or neither.

2) If I want to have more than 1 VI in the software, what is the best way to send data from one VI to the other VI? SubVI has input and output wires. So it is easy. But VIs do not. Basically I want to have Main VI where I get all the information from the use through a front panel and then go off doing my data acquisition. I want to keep the Main VI as clean as possible. There will be some operations which will need only 1 input and will have only 1 output. But this operation will be used only once in the who operation. So can I have this operation all in a VI and then call it in the Main VI?

There is no difference between a VI and a subVI other than semantics.  Both are completely independent excecutable portions of code.  Your main or top-level VI can have inputs and outputs as well.  You could execute it stand alone, or it could become a subVI of an even higher portion of code in your hierarchy.  The only difference between the two is that a subVI is just a term to distinguish it as being a portion of a higher level of code.  There are multiple ways of passing data between VI's.  One is wires.  When a subVI ends, the data on its indicator that is connected to the panel is available to travel down the wire to another portion of code.  Another is global or shared variables which stores data to be used by multiple locations.  Another is a function global variable, a LV2 style variable, or action engine.  All of these use special characteristics of uninitialized shift registers to store data between calls of that subVI.  Other methods of sharing data are on the Synchronization pallette such as queues and notifiers to store and pass data.

Using a subVI, even it used in only 1 location can help keep a portion of your block diagram clear.  It gives you the ability to hide some details such as a complicated algorithm.  You can write an algorithm as a subVI and it gives you the ability to test the inputs and outpus as a standalone.  Once you have that. You can drop it in and use it even if it is only at 1 location.  If you need to change it, you can modify the subVI and test it without risking the corruption of the rest of your main VI

3) If I have 3 different VIs in my application, and I define something (say an array) in the Main VI or for that matter second_VI.vi in my application, will that be available in the third_VI.vi ?

Possibly, it all depends on which of the methods listed in number 2 you would like to use.

Thanks in advance.

---

[Drewski]

---

Britoa wrote:

---

Drewski wrote:

As for how and when to use sub-vi's there are probably as many opinions as programmers.  I suggest you develop a style that works for you.  Until you develop your own style I suggest you use sub-vi's to limit the size of the code on the screen to two horizontal screens, scrolling left to right.

---

I agree with most everything you said, except the scrolling part.  I hate to make code that makes me scroll.  I understand sometimes, when your init block is just off to the side, and your exit block is on the other side, it gets close, but anything more than that and it's too hard to follow.  As for sub-vis, I go by the rule of thumb that if it takes more than one or two lines to describe base functionality, it should be split into sub-vis. 

---

Yes, I do not wish to start a never ending debate (which I already went through with a co-worker), however, in Code Complete it is suggested to limit a function to 4 viewable screens, which I believe is roughly equivalent to 2 scrollable screens in a graphical programming environment.  Personally I attempt to limit a vi to one visible screen (see, agreeing with you) unless there is a compelling reason not to.  And when giving style advice to beginners I try not to set any rules for them as they may take it as an absolute instead of a guideline.

[labview_beginner]

Thanks for the responses. 

The way I create a subVI is Edit -> Create subVI.

At that point, Labview by defaults puts all the controls as inputs to the subVI and all the indicators as outputs of the the subVI. But what if I do not want all the controls to be inputs? Some of the controls may belocal to the subVI and do not need to come from out of the subVI. Please see the "set current"example that I have attached on my previous post. In tthat case none of the VISA instuments need to be inputs to the VI. They could be locally defined and used within the VI instead of coming from outside the VI.

Thanks. 

[Drewski]

After you make a subvi you can go in and change the control to a constant, if that is what you mean by making it local to the subvi.  Then delete the control from the vi that is calling the subvi.

The above answers your question, the below may confuse you, so read at your own risk!  🙂

You can also disconnect all the controls and indicators, change the pattern and reconnect the controls and indicators as you see fit.  The create sub-vi function creates a sub-vi with the minimum amount of terminals that are used by the sub-vi.  You can also make a sub-vi by creating a new "blank.vi" and then saving it with a name and then adding it to the block diagram with the "select vi" option.

Edited: You can implement a parameter file, see examples in LabVIEW, and store the GPIB addresses of the instruments in the parameter file, then read them into globals and use the globals in the sub-vis to avoid passing the address all over the place and having hard coded addresses in the application.  You don't need to have a parameter file, but it is useful to get a parameter file working and then use it for storing constants instead of hard coding them into the application.  You don't have to use a parameter file, you could, in an initialization block for example, set the globals from the constants and then use the globals as above.  To create a global's file, place a blank global from the programming -> structures on the block diagram, then double click on the global and save that "vi" as "Globals.vi."  Then add controls to the globals.vi front panal and save it.  Then you can "select" a global by right clicking on the global you placed originally.

Message Edited by Drewski on 11-14-2008 06:34 PM

[pnielsen@gplains.com]

Is it possible to hide portions of the front panel with a password.

[RavensFan]

Why did you post to a 1 1/2 year old unrelated thread?  You should have started a new thread.

What do you mean by hide?

You have a few options.  1.  Use a tab control where some tabs are disabled until the user has entered the secret password.  2.  Use other controls or objects such as a picture indicator to cover up certain parts of the code.  If the user enters the secret password, then your program can hide the picture indicator thus allowing the parts of the front panel underneath to show.  3.  If you have your front panel locked to certain dimensions and scrollbars not shown so the user can't maneuver around to the wastelands of the front panel, then you could programmatically move controls and indicators to locations that would be offscreen.  Secret password entered?  Move the controls back to their original positions.