LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How do I make this a sub VI

Solved!
Go to solution

Yes, I agree. But I don't have enough experience to really know. But I have read that NI discourages the overuse of sequence structures. How ever the test engineer where I work uses them almost exclusively. As a matter of fact we were going to collaborate on a project and the first thing he say's is " we're not using any state machines". I don't know what to think. What is the reality of using or not using sequence structures.

0 Kudos
Message 11 of 19
(1,723 Views)

Thanks again. Could you explain a little of the reasons you modified the way you did. I mean, it seems as though there are some things you cannot do if your making a sub VI. Are event structures not good? Local variables? and it seems anything on the front panel is outside of the while loop. Are these general considerations when converting to sub VI's.

Mark R Rivet
0 Kudos
Message 12 of 19
(1,715 Views)

If you have a VI that is based on user interaction with the front panel, then you need to show the front panel.  That's a simple fact.  If you call it as a normal subVI, they don't show their front panel by default.  So make sure you have the setup of the subVI to show front panel when called.

 

Local variables, when abused, cause problems called "race conditions".

 

Sequence structures get used to try to fix the problems that abuse of local variables called.  The problem with using them it that it makes your programming very inflexible.  A state machine allows you to do things in a sequence, but with the flexibility to change the order of things as needed.  If your test engineer refused to use a state machine architecture and insisted on sequence structures, then he wasn't a LabVIEW programmer and was just hacking his way through his job.

Message 13 of 19
(1,709 Views)

@LeatherNeck wrote:

Thanks again. Could you explain a little of the reasons you modified the way you did. I mean, it seems as though there are some things you cannot do if your making a sub VI. Are event structures not good? Local variables? and it seems anything on the front panel is outside of the while loop. Are these general considerations when converting to sub VI's.


If that was for me, then the reasoning is simple:
1. Locals and sequence structures should Always try to be avoided, they often cause more problems than they solve.

2. You usually want most SubVI's to work similar to the built it functions, like Index Array, Read file or what not. So, you (usually) want them to just take some inputs and give some answers. Imagine if Add popped up a dialog box asking for the values each time …

3. If you DO want the front panel and user interaction to occur, like in a Setup dialog (the dialog being key here) set the VI property to "Show when called" (then event structure for handling button presses is the right way to go).

As a rule of thumb, only dialogs should be "Show when called", thus only they are OK to require interactive user inputs, all else should just be fed values and spit out results. Makes sense, right?

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 19
(1,689 Views)

Well, yes, makes sense. But one more thing please. This filter wheel program needs input. Well, user has to select which filter is in use. So that needs to be on my main front panel. I guess the question is if you are creating a sub vi  that requires a control for a selection, is that fine for the sub vi. I'm going to guess yes. I know, it sounds like I have no clue. Its just that my mind is swimming with concepts from core1 & core2 and I 'm trying to connect it all in my head. So I mean, it must be ok to have some front panel controls and indicators that originate in the sub vi, yes?

Mark R Rivet
0 Kudos
Message 15 of 19
(1,678 Views)

Take what Yamaeda did for you into two sub-VIs. The first sub-VI will have the while loop and should return the VISA reference when completed. The rest of the code goes in the second sub-VI that you call passing the position you want and that sub-VI will return info that you can display on your FP.

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 16 of 19
(1,668 Views)

Thanks. I have a lot to learn about sub vi's. Can you point me to some books or references specific on the subject?

Mark R Rivet
0 Kudos
Message 17 of 19
(1,664 Views)

@LeatherNeck wrote:

Thanks. I have a lot to learn about sub vi's. Can you point me to some books or references specific on the subject?


None really needed. Think of all the built in functions as Sub VI's. The only difference is that you build and design these. (Some of them are normal VI's and can be opened and if you look in the Help for examples you'll get plenty to compare to).

To your previous question, yes, you can Place Controls in your Main VI and send those values through the Sub-VI. That's actually the whole Point. 🙂 (once again, compare to the built in functions, like Add).

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 18 of 19
(1,657 Views)

Ok, that makes sense. I will dig into the sub vi's that Labview comes with. That'll give me a great idea of how to handle certain things. One more question, if you don't mind. I have taken core1 and core2. Will core3 help to pull core1 and core2 together? should I take the core3, or just keep plugging away with what I have. So my core1 and 2 were done this July.

Mark R Rivet
0 Kudos
Message 19 of 19
(1,651 Views)