I want to include everything in my sub vi.

[ASH2020]

Hi all.

I am trying to make a sub vi from a working vi and when I do, by highlighting it and choosing Create SubVI on the Edit menu, it does this:

Starting vi

Sub vi

I can sort of understand why the indicators (3 graphs) are outside but I really want the cluster of information at the left to be included.) Any ideas how I can do it?

Thanks

Andrew

[altenbach]

How do you expect the cluster to receive data from the caller?

If the cluster never changes, you can replace it in the subVI with a diagram constant and delete the control.

(One subset operation is probably sufficient, you could even use "string subset" directly. There are typically better options than using "bytes at port")

[JÞB]

Change it to a constant

[Bob_Schor]

We can't see where you drew the box saying what you wanted included in your sub-VI.  I've never been happy letting LabVIEW make my sub-VIs for me -- if I want to do that, I open a blank VI, go to its Block Diagram, copy the code (nicely formatted) that I need into the Block Diagram, add missing Controls and Indicators and wire them as I want to the Connectors, including the Error Lines.  Doing it this way, with recent LabVIEW versions, New VI gives you the default, preferred 4-2-2-4 Connector Pane, so you have Error In/Error Out in the right place, spacing consistent with many other Functions and Sub-VIs, and no "guessing".

Now go back to your original VI from where you removed the code.  Put your new sub-VI on the caller's Block Diagram, and wire up the inputs and outputs.  Takes about the same amount of time, but results in a much neater, much more intuitive process and package (at least, for me it does).

Bob Schor

[natasftw]

Why don't you like letting it make the subVI for you?  The only things that stay outside are controls/indicators so they can send/get data from the subVI.  Constants get dragged in.  It does pretty much exactly what I'd want.  I'm curious what use case you've been using where that isn't true.

As for the OP, why do you want it inside?  If you want it to be modified, you need it outside.  If you don't, delete the input.  Open the subVI.  Set the values you want and make them default.  Ensure the input is Recommended instead of Required.  Then, you can modify it later by adding an input cluster or you can let it use your default values.  If you NEVER want to change them, make it a constant in the subVI and everything goes away.

[billko]

---

@Bob_Schor wrote:

We can't see where you drew the box saying what you wanted included in your sub-VI.  I've never been happy letting LabVIEW make my sub-VIs for me -- if I want to do that, I open a blank VI, go to its Block Diagram, copy the code (nicely formatted) that I need into the Block Diagram, add missing Controls and Indicators and wire them as I want to the Connectors, including the Error Lines.  Doing it this way, with recent LabVIEW versions, New VI gives you the default, preferred 4-2-2-4 Connector Pane, so you have Error In/Error Out in the right place, spacing consistent with many other Functions and Sub-VIs, and no "guessing".

Now go back to your original VI from where you removed the code.  Put your new sub-VI on the caller's Block Diagram, and wire up the inputs and outputs.  Takes about the same amount of time, but results in a much neater, much more intuitive process and package (at least, for me it does).

Bob Schor

---

Ever since LV 2012 or so, letting LV make your subVIs has been a viable option.  It will try its best to give you a 4-2-2-4 pattern with error inputs and outputs at the bottom unless you have more wires than that pattern can handle.  Each version of LV more recent than that improves upon the experience.  In LV 2014, the terminal labels are oriented correctly for controls and indicators, and the front panel is reasonably organized.

If I want wires that aren't connected to anything I want to include, it's a simple matter to enclose the stuff to be included within a sequence structure - or even an error case structure if you want to capture the error wire - select the structure and make the subVI.  You can always reconnect the connector pane if you don't like how the auto-wiring came out, but usually LV is really good at guessing.  The stuff inside may be a jumbled mess, but exactly the same mess you'd get with a cut-n-paste - except that with cut-n-paste, you have all those broken wires to tend to.

Of course, I am pretty good at avoiding this in the first place because I'm pretty good at anticipating what should and shouldn't be a subVI, but there are times when you look at a piece of code - especially something you inherited - and say, "Wow, that should be a subVI".

Bob, LV has made tremendous strides in this area since LV 7.x.  😉

[ASH2020]

Thanks for all the replies. I've been away for a day and now I can get on with it!

The cluster never changes in this case, I hadn't thought it would be as easy as making it a constant. Thanks for that. Interested in the alternatives to "Bytes at Port". I need to get the buffer as fast as possible, without putting a delay there, i.e. as soon as the bytes are available. I would welcome any way of speeding it up.

Andrew

[ASH2020]

Ideally, in this case, there isn't a need to specify what, it is everything in the picture. I will try the other way of doing it. Thanks for the suggestion. I know it is nice and modular to use sub vis, but isn't there a danger of getting sub-sub-sub vis that never see the light of day that cause trouble if they are used somewhere else and then maybe changed a bit?

Cheers

Andrew

[Bob_Schor]

I believe that most VISA devices can be configured to send a "Termination Character" (often a Line Feed, hex 0A) when all the bytes have been set.  So I configure my VISA to stop reading when it sees the Termination Character, and when I want to Read (because, for example, I've just written a Command and expect a Response), I do a read of 1024 (a nice round number, anything will do as long as it is greater than the longest expected string).  The VISA Read will "block" until the Termination Character is read, then will proceed, guaranteeing the minimum Wait Time.  Reading "Bytes at Port", in particular, might result in your missing some bytes -- suppose you send the command "Give me the Gettysburg Address", and VISA starts sending, say, all 1000 bytes (that's a guess, by the way).  You ask for "Bytes at Port", it says "79" (because it's slow), and you read only the first "Four score and seven years ago, ..." 79 characters, not realizing more were to come.

Bob Schor

[Bob_Schor]

A Followup to my comments about my not using Create SubVI.  Yes, I first learned about this when I was starting with LabVIEW, around 7.x.  I had the good fortune to stumble upon Peter Blume's "The LabVIEW Style Book", which I read cover-to-cover at least 4 times, and became convinced that one difference between Good LabVIEW Code and Less Good LabVIEW Code was "Style", such silly things as keeping wires straight, using 4-2-2-4 Connector Panes even if you only have 2 inputs and one output, (almost) always using Error In/Error Out, designing modular sub-VIs, not being afraid to use sub-VIs, etc.

So I do try to "design it right" the first time, which makes it less likely that I will need to "carve out part of my code" to make a sub-VI.  Instead, when I get an overly-large Block Diagram that begs to have part of it "split out", my current practice is often to "Duplicate and Whittle Away", or to "New VI and Copy and Paste", leaving me with little to do except create Controls and Indicators and wire them up to the Connector Pane.  [Of course I also need to create a VI Icon, write a Description, etc. ...].

I have a colleague who has been using LabVIEW longer than I, and who still uses two of the largest monitors he can afford, side-by-side, so he has enough room for his single Block Diagram (though he usually needs to scroll vertically), with wires everywhere, rarely straight.  He knows when he asks me to help I'm going to make some snide remark, then start carving his code into sub-VIs (which I do sometimes "pinch out" with Create SubVI, as it is too painful to isolate in the morass of wires), but we then end up with a hierarchical VI that have sub-VIs that illustrate what is being done, hiding within the sub-VI "how" we are doing it, and now the logical and computational problems become clear and can be fixed.

I'm glad to hear that Create SubVI is now much more "Style"-ish.  I might give it a try, particularly when handed a plate full of LabVIEW Spaghetti ...  Thanks for bringing me up-to-date ...

Bob Schor