LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
X.

A natural approach to new subVI creation

Status: New

Expanding a little on the idea I hinted at in this recent thread, here is something that strikes me as a missing feature in LabVIEW.

I'll start with some illustrations.

 

Starting situation: let's say I have a main VI and I create a new case in a case structure, because I need to perform some data processing. I drop a few property nodes, references, have data flowing from shift registers left to right , and I pull a Data Value Reference wire from a big data structure:

 

ScreenHunter_006.jpg

 

New feature 1: I drop a BLANK VI on the block diagram (which I choose with the appropriate number of connectors):

 

ScreenHunter_005.jpg

 

New feature 2: I now CONNECT my inputs and outputs to this blank VI:

 

ScreenHunter_005.jpg

 

ending up with this:

 

ScreenHunter_001.jpg

 

New feature 3: Now, I can double-click the blank VI to open its panel, which reveals a neat FP and a BD with the Controls and Indicators I need (not shown). I now can start wiring the functions I need to implement.

 

I'll comment on the idea next.

 

 

 

12 Comments
X.
Trusted Enthusiast
Trusted Enthusiast

As I said, I thought of this after suggesting something else which I still think is of value: being able to create new connections to an EXISTING subVI, from the calling VI. Take a look and vote for the idea here if you wish (although of course, as we all know, the guys developing LV might just ignore it). The idea's motivation was to reduce the number of clicks needed to perform an action which I found myself doing over and over again...

This idea is a natural extension of this concept, and as I also discuted in my comment in the linked thread, it is driven by the absurdly convoluted way we are currently forced to adopt to create new subVIs. I have suggested some simplifications in the past (here and here), but I think this would make those redundant.

Don't get me wrong, the existing ability to create a subVI from a set of selected objects in a diagram is a powerful feature, but as we all know, it usually results in some absurd connections to the newly created connector pane (and some mess on the BD). And this is because it has been designed for a different situation, that is when you have a piece of code you want to abstract into a subVI, for reusability or because your diagram has started growing beyond reason.

Note BTW that the philosophy of providing the user full control on how to connect things I am suggesting here could very well be extended to the Select Objects > Create subVI situation too. But that is matter for another idea, I suppose.

 

AristosQueue (NI)
NI Employee (retired)

I like this more for new VIs than I do for existing VIs. For existing VIs, the possibility of accidental miswiring seems pretty high to me. And for existing VIs, there would be weird cases involving Undo -- LV typically does not do undo across multiple VIs because that leads to strange cases where undo is sometimes possible on a VI and other times not depending upon whether the other VI has had any edits in the interim. For new VIs, these problems don't exist, so I like this variant more.

X.
Trusted Enthusiast
Trusted Enthusiast

If the feature (for existing subVI) is implemented with a power-user lock (a special combination of keypress and mouse click), I don't think "accidents" will be a problem. Undos might, but as usual, I am not concerning myself with this kind of considerations... But I'd be glad to incorporate any subsidiary features this idea requires! Like a more powerful undo...

altenbach
Knight of NI

AQ, what is your definition of a new VI? Anything that has not been saved yet (untitled X.vi)?

 

Maybe it should not be a VI, but a special structure from the pallette that looks like a connector pattern (named e.g. "SubVI skeleton") and it can be placed on the block diagram. We can select any connector pattern and wire it up. Once we are happy, we right-click it and turn it into a SubVI, which then opens and has all the desired connectors assigned to suitable FP objects. (should I write this up as a seperate idea?)

 

I think the idea in the other thread is too general because it can mutilate existing VIs (even in VI.lib).

Darin.K
Trusted Enthusiast
I was about to comment that your other idea was very close to an XNode I had written. This one is almost exactly it. I drop the XNode, choose connector or leave default 4-2-2-4, and wire away. At the end you right-click and get the new subVI. I like that the code is always executable during the process. I will see if I left the code in a distributable condition. Pretty easy job I remember.
X.
Trusted Enthusiast
Trusted Enthusiast

VI, function, XNode, I'll by that for a dollar...

fabric
Active Participant
+1 for being able to drop a blank connector pane, wire it, and then convert to a new sub VI... That would be enough for me! Magically adding terminals to existing sub VIs would be interesting but I could live without it.
altenbach
Knight of NI

Darin wrote:  I like that the code is always executable during the process.

 

How exactly are indicators (=subVI outputs) handled. How do they know their datatype?

Darin.K
Trusted Enthusiast
That is the voodoo I need to look over. I remember three methods I incorporated: left side terminals could be set to pass through, a menu of arrays and scalars of basic types, and a source could be wired, disconnected, then the terminal changed to output. The few cases not handled could be added after subVI generation.
JÞB
Knight of NI

This gets my vote!  I'm very leary of extending it to existing objects "reuse code" would need some protection or every new LabVIEWer is going to break everything.  But dropping a new conpane that gerenates a FP and BD---Sweet.  (And if you wanted to be really nice to me could you give it a RCM to merge a VIT into the beastie):smileysurprised:  At least the basic design patterns- Sub.vi with error handeling etc...


"Should be" isn't "Is" -Jay