LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
fabric

"Pseudo VI" - The end of single use sub VIs

Status: New

There are many reasons to create a sub VI, but one of the most common reasons is simply to reduce block diagram clutter.

 

For example, I'm developing a user interface VI and some part of the code starts to get too big for the available block diagram space... After pushing the limits of sub VI density and exhausting all my clever wiring tricks I eventually surrender to the fact that I need to create "yet another single use sub VI"... 

 

This is one of those things that always bugs me. Why?? Because I know I'm adding some project load time, an execution performance hit, some file system clutter... and all I'm getting in return is a sub VI that will never be used anywhere ever again. 

 

So here's my idea:

Allow creation of a "pseudo VI". It would work just like creating a normal sub VI, except no new file would be created. Rather, its code would remain as part of the parent VI, but it would appear as its own entity on the block diagram (just like a normal sub VI).

 

  • The pseudo VI would have a name relative to the parent, e.g. "myLlibrary.lvlib:myParent.vi:myPseudo.pvi"
  • It would be visible in the project as a child of the parent VI
  • In practice it would behave something like an inlined sub VI
  • Because its code would reside inside the parent VI there would be minimal/no performance implications arising from its creation
  • A menu option would exist to convert the pseudo VI to a normal VI
  • (As an aside, this may also be a good way to achieve the "hard inline" functionality described in this idea)

 

pseudoProject.png  pseudo.gif

9 Comments
RavensFan
Knight of NI

This sounds a lot like other ideas:

 

Macro VIs and Code Fragments

Collapsible Code

Macro in LabVIEW

 

fabric
Active Participant

Hi Ravens, thanks for the links... there is definitely some similarity there!

 

Just to clarify my particular angle:

  • I prefer the idea of a "single instance" pseudo VI, rather than a reusable Macro VI (To me, reusable = subVI)
  • I like my implementation ideas more than those in the linked ideas Smiley Wink... especially creation, namespacing and project appearance
  • Inline VIs are not quite sufficient beacuse they add extra files to my already large projects
  • Packed project libraries are not quite sufficient because they don't allow packed code to be easily manipulated

 

SteenSchmidt
Trusted Enthusiast

I have never had a problem with "single-use" subVIs. Why reinvent something that already exists as a VI? "Pseudo-VIs" would look so much like ordinary VIs that the only difference would be that it can only be used in one place, which I see as an unnecessary constraint. It would need to have all the documentation features of an ordinary VI, an icon, an FP, terminals, a conpane etc. If you'd want any of that to go away, you're back at collapsible code or code fragments (which are already suggested). If you worry about the call overhead of an ordinary subVI you just inline it.

 

Making subVIs is the process of encapsulation, modularization, and general house-keeping or code segregation to be able to verify that your application works as it should. I think subVIs fulfills this use case plenty. When you do this enough, opportunities to reuse the code at other places in your application often presents itself, so making subVIs in fact promotes good design.

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
SteveChandler
Trusted Enthusiast

I am giving a kudos for the spirit of this idea and the several other related/similar ideas. I think that something good could come from the general concept. I do not like the name "single use vi". I want to reuse anything that I write! So my kudos is based on reusability.

 

What I would like about this: I would like to see some kind of a "mode" or save as option where all of the subvis are packaged together with the caller. Much like an llb but without the name collisions. This would be VERY useful for posting example code. More often than not I open an example that is missing subvis. Not to mention that it is faster to load a large file than several small files.

=====================
LabVIEW 2012


SteveChandler
Trusted Enthusiast

@fabric: "Packed project libraries are not quite sufficient because they don't allow packed code to be easily manipulated"

 

You might want to vote for the Bundled Project Library if you have not already.

=====================
LabVIEW 2012


fabric
Active Participant

Thanks Steve - and yes, I already voted for bundled project libraries. I often work with large projects and I *really* like the idea of less files without sacrificing good architecture.

 

@Steen - Yes, creating a pseudo VI would be pretty much the same amount of work as creating a sub VI. In fact, I think they *should* be as interchangeable as possible. My main gripe is with adding extra files which obviously add load time and performance hits. Inlining helps with performance (great work NI!) but we are still stuck with increasingly large projects (i.e. many FILES) - particularly when developing good class-based architectures with lots of accessors, etc.

JackDunaway
Trusted Enthusiast

Would this make Unit Testing more difficult, without access to a public interface to the function? (This type of module interface seems privately scoped to the owning diagram) The idea of fewer VIs is completely enticing, but complicating Unit Testing might be a showstopper.

Jason_Harrigan
Member

I, for one, an discouraged from cleaning up my code for single use or limited use vis, to the point of tolerating somewhat cluttered code. I don't want 5000 vis in my project. Also, if I'm going to take the step and make a subvi, I am going to be sure to do the following things:

1) come up with a good name for the vi. Not some random and confusing name.

2) create a front panel image

3) create limited documentation..in most cases

4) compact multiple wires if there are more than 4 or 5 into logical clusters

5) typedef the clusters! which creates a typedef file

 

However, if no one ever had access to my vi and it was hidden within my code, it becomes much less formal.

AristosQueue (NI)
NI Employee (retired)

JasonH: Does your opinion of single-use subVIs change when you're developing in a library and you can mark the subVIs as private? No one has access to them then except your library.

 

I do like this idea, and I have kudos'd it, but the topic of access to subVIs intrigued me. 🙂