"Create SubVI" is doing nothing at all; no error message, but no action

[Photovore]

Hello gents and ladies!

I've inherited a huge block diagram (48x my screen area) and wish to simplify it, so I want to sub-VI chunks of it.

At the lowest nested level, I've bundled/unbundled to reduce in/outs as is required (down to 24 now), and the Create SubVI menu item does nothing; error, no results.

Trying this at higher levels, it says ~"too many terminals" and warns ~"contains Event struct/may change behavior", so I went all the way down to begin at the innermost-nested T/F case struct. The functionality I wish to enclose is selected here:

(It also doesn't work if I select what's *inside* this struct)

Here we are looking at:
...... a Case struct
inside a Case struct
inside an Event struct
inside a While loop
inside an In Place Element struct
inside a While loop
inside a Case struct
inside a Case struct
inside a Case struct
inside a While loop
...Most of these span multiple screen widths, up to ~10 for the outermost While.

You might say "rewrite this from scratch", but I'm only 10hrs/wk; the lab doesn't have the budget for more and also can't wait that long. I've hand-drawn diagrams to try to see what's happening; diagonal scrolling 10x screens to follow dataflow is maddening. I've met stronger programmers but I'm no slouch, having coded C, Objective-C, C++, C#, Java, Javascript, OpenCL, RenderScript, Python, R, etc. and written a couple specialized languages. I'm pretty new to LabVIEW though.

(It seems not-wise to have an event struct buried like this, but if I can get the overall schema visible, I can address event issues afterward.)

Any thoughts or ideas? Why is Create SubVI doing nothing and yet not saying why? (Also, if I were to manually create a SubVI, would that be wasted effort? I would SO much rather use the tool as I move up through these layers....)

Many thanks for any input!
Dave

p.s. LabVIEW version is 2021; Windows 10 under Parallels

[Bob_Schor]

The "default" Connector pane is called the 4-2-2-4 pane (four Inputs on the left side, with the lowest one "reserved" for Error In, 2 "mostly never-used" input and Output terminals at the top (center) and bottom (center), and four Outputs on the right side, with the lowest one for Error Out).  Good designs rarely use the top and bottom central terminals, and usually do not fully populate the "side" terminals.

But what do you do when you have to deal with, say, 10 "descriptors" you need to use inside the sub-VI?  You try to group these descriptors into a Cluster (which lets you mix types, and to label each of the components to they "make sense to you").  Now you only need a single connector.  Inside the sub-VI, you can use all or a subset of the components, depending on what you unbundle.

For this to work, you need to take a step back and try to "see the big themes" that can guide you into seeing how the 40-80 individual "wires" relate to each other, and can be naturally grouped into "logical components" that can be put into a Cluster (and, if you do this, you really need to make a TypeDef of your Cluster, which is another trick that will help you in your coding).

When you have a 48-screen VI, you really do have a serious problem that requires creating (many) sub-VIs.  Let's consider that a screen is 1920 x 1080 pixels.  A VI is 32 x 32 pixels in size.  We can easily put 10 sub-VIs across the screen (taking up 320 pixels, leaving 1600 for "spacing") and 5 "rows" of 10 sub-VIs vertically with 920 pixels for spacing.  You probably don't need 50 sub-VIs in the top-level VI.  Of course, you don't want a 2-D structure, you want a 3-D structure, say something like a State Machine or a Queued Message Handler (or the DQMH version).  Most LabVIEW programs fall naturally into such a multi-dimension model -- there are a sequence of things you do, usually in temporal order (you do "Initialization" first, then "Configuration", then "Set parameters", then Something Else, and somewhere you have "Handle Errors", "Close down DAQ", and "Exit".  Each of these Steps can use 70% of the Laptop Screen area, particularly if you "hide the messy details" inside sub-VIs, run "persistent sets of parameters" across the top of the While Loop that contains the main code in Shift Registers (where all of the "cases" inside this While Loop can have access to them, reading and modifying them as each "State" dictates).

A 48-screen VI is almost impossible to maintain, modify, or understand [I've been there].  There are LabVIEW experts and consultants out there who may be able to help you restructure this code, breaking it up into logical units and putting it into an understandable framework.

I almost forgot to ask -- are all of the routines you're working with documented?  Particularly is the 48-screen VI documented?  Writing documentation for "tiny" sub-VIs that use the 4-2-2-4 connector and does one thing well can usually be done in three lines of text + the naming of the (typically 2-4) inputs and outputs.

Bob Schor

[UliB]

Your image shows 24 tunnels on the case structure plus 1 input for the case selector (this would go in the subVI too).

There are also a property node and an invoke node, both linked to a front panel element (image out). And there are two references to front panel elements (Delete Colonies and Add Colonies). These four elements would require a reference input on a subVI. There may be other 'links' to front panel elements in the false case which would require additional reference inputs, but we can't see.

In sum I'm at a minimum of 29 inputs and outputs for placing this code in a subVI. As far as I know 28 is the maximum for a connector pane.

I think you have to put some more elements in a cluster to reduce the number of inputs and outputs.

You could put references for 'image out', 'Delete Colonies' and 'Add Colonies' in a cluster as a starting point.

[Kyle97330]

One thing that I did in much older applications that I made (that I do not do any more) is that for my main VI I would put a section of code on the block diagram of the top VI that would put all control and indicator references on the diagram into one global VI, which can then be pulled out by any subVI at any depth as needed to write values to them. This would effectively be a "WORM" global, write-once-read-many, so it would avoid some of the problems associated with global variables, but would still be an imperfect solution.

I no longer do this and would usually not recommend it, but assuming that quite a lot of the references that you need to pass around are likely references to front panel controls that need to be updated by subVIs, this might be a viable approach to take to start to get this code you've been saddled with under control.  Whether this would help a little or a lot depends mostly on parts of the code that I can't see, though.

[Photovore]

Thanks; this should help to get a toe in the door.  I did not consider that the front panel refs etc. would add to the allowed 28 terminal count.  (I've done a little more bundling but not cracked it yet.)

Cheers!

p.s. False case seems to ref another fp cluster (test unbundling bottom left):

[Photovore]

Thanks!  This should help with issues from the buried event struct as I refactor; most are likely updating on-screen exposure time / exposure number / elapsed time / channel number / etc. as well as controls to define ROIs, add colonies, and so on.  (We have i.e. cyanobacteria luminescing in petri dishes on turntables.)

"...depends mostly on parts of the code that I can't see...." -- I can hardly see them coherently myself, sir!

[Photovore]

This is a really helpful reply, Bob; thanks. With this and the other two, I feel at least a squidge of hope. Much more than I felt before.

I do think I'd want to write a state machine if I were doing this from scratch. Don't know QMH/DQMH but would look at those, again if....

This is a rewrite from Pascal source on a Mac ca. 2010, when the old cameras failed and were unreplaceable and Mac drivers were not available for the new ones. If I had that source (which seems unavailable) I'd consider porting it to C on the PC and calling the couple-dozen camera and motor SubVIs from there. The author of this iteration wrote it for her Master's thesis; as I said on a reddit thread, Shai-Hulud alone knows how much spice she consumed to achieve the necessary state of fugue.

In-code documentation consists of the names of VIs, the names of cases (if not just T/F), and the names of controls, indicators, and terminals. I think I saw one floating text label somewhere that I didn't put there myself. Aha!, there are five better-annotated block diagram chunks in the thesis itself (simplified to each fit on one page, illustrative / not real code but should be helpful); I've been negligent in not printing those out.

(Mac just crashed; thankful for auto-save.) This will be quite a slog, but I guess I live for learning!  Thanks again for all of the advice.

Dave

[Photovore]

Hi again, folks. Still having trouble with Create SubVI.

I've bundled it down to 12 terminals including selector. (Yes it should be fewer still, but just going for proof-of-concept here.) I don't think there are enough refs internal to the struct to break the 28 limit. Create SibVI still just hums to itself for a moment, producing neither results nor error message.

Here are both True and False cases, cleaned up (though still ugly I know).

Any ideas as to what might be wrong? (I know modcolonies is quite ugly, but, clean run arrow.)

Thanks for any help!

Dave

(p.s. i don't know enough of how this forum works to know if you'll see this reply; i hope so)

[Kyle97330]

OK, I have an idea that might give more information or might just be a waste of time.  Follow these instructions:

1. Go to your Options menu and enable VI scripting (if you haven't yet).

2. Have your mega-VI open.

3. Create a new, blank VI.

4. Create a Static VI reference on the blank VI.

5. Insert your mega-VI into the static VI reference (drag and drop the icon on it, or right-click and choose "browse for path"

6. Create a property node from the static VI reference and choose "Block Diagram" (this is only visible if you enabled scripting earlier).  Wire the static VI to the property node input if not already done.

7. Add this VI to your blank VI's block diagram: 

<Your LabVIEW directory>\resource\plugins\PopupMenus\edit time panel and diagram\Create SubVI from Selected Wires.llb\CreateSubVIWires_Create SubVI Method.vi

8. Wire the "Diagram" output of the property node to the input of that VI.

9. Create an "error out" indicator from the output of that VI.

10. Go back to your main VI and select exactly what you selected before when choosing "Create SubVI" before when it failed.

11. Make sure to keep that as the selection while you go back to the blank VI that you made.

12. Run the blank VI that you made.

It could take a while or fail instantly.  When it is done failing, check the error out indicator on your blank VI.  If you're "lucky" there might be a failure code and some details as the output in the error out terminal.

Doing all that is basically a way to make the system show you the error it generates when it runs its internal code to make the subVI.  Since we can't see that, intercepting the error in this way is the only way I can think of to try and get more information apart from just trial and error repeatedly.

As for whether or not people will see this reply... replying to your original post is the best way to go.  It puts it at the top of the list of posts again, and it bolds it for anyone who read it before to show that there are new unread posts in it.  Usually doing that is good enough to catch people's attention, especially if you haven't yet set one of the replies as a solution to the problem.