LabVIEW Idea Exchange

My forum question asked here: http://forums.ni.com/t5/LabVIEW/Determine-and-Minimize-LabVIEW-Build-Dependencies/m-p/1441734 has prompted me to post a New Idea on this exchange.

    To summarize:  LabVIEW executables tend to be on the LARGE side especially when driver packages like DAQmx, VISA amd IMAQ are required.  I'm asking if NI could add some enhanced functionality to the Application/Executable Builder that assist the user in determining and minimizing the size of the final distribution package.  Ideally this would be a completely automatic function that would simply minimize the build parameters to the smallest possible set after analyzing the active project.  Additionally, it would be great if this would be smart enough to pare down the driver package itself to the bare minimum.  (I.E. It shouldn't require a 150MB DAQmx package size to read a few thermocouples with a 9211 module.)

    At the very least, the Additional Installers tab should show the size of the packages you're checking off and the resulting installer's total size.

An example of the size increases of required installer packages for a simple DAQmx application:

The "Coerce dots" are handled by LabVIEW as Visual warnings ... but a bad type coercion could have very bad issues ! 

It should be nice to be able to find all "Coerce dots" in all the VI's of a project, in order to check if they are critical or not.

[admin edit] This functionality is currently available with the VI Analyzer Toolkit (included with a LabVIEW Professional license or available for separate purchase). Specifically, you can run the Block Diagram > Performance > Coercion Dots test with the 'Block Diagram' option turned off, and the 'Single Wire' option turned on with a 'Maximum Number' of 0:

If you run the test with this configuration, it will return a failure for every coercion dot in the analyzed code.

Note: The idea will remain open, but we're mentioning the workaround here for the benefit of users who need this functionality today and find this Idea Exchange post via search.

If I "create constant" from a path input, and start typing into the path, the control grows to the left, away from the function that accepts it as an input.

But for VISA and IVI, the name controls grow to the right as you type into them, covering up the icon of the function that accepts the input, along with the wire connecting them.  Let's make VISA and IVI behave better.

Every now and then I (or others) have two case or event structures that I would like to merge, either completely or just copy some cases from one to the other. If we are talking about one or a couple of cases, doing it by creating empty cases and copying the code from one structure to the other as is the option today is fine. If the number is much higher this gets quickly tedious, and we have to come up with alternative solutions.

(Making a subVI of the two and add another case structure around them, as described in the discussion linked to above, is one -  but that changes the layout and adds another selection to the logic).

So how could it be handled by the IDE instead and made much easier?
A case merger function.

Here are a few quickideas on how to implement it (but any similar solution would be better than none);

1.  Copy-Paste-Merger: Selecting the frame of structure 1, copying it, selecting frame of structure 2 and pasting will bring up a merge dialog with the following options:
   
   a) Replace structure?
   b) Merge structures (all cases)?
   c) Merge selected case only into structure?
   
   Now if the user selects to merge the whole or just the top/selected part of the structures (b or c) the function has to handle overlapping cases (just like the OS does when copying into a folder with existing content) by asking the user whether to keep the old ones, replace with the new ones or leave them as non-unique values (or add an index to the value) for the user to tidy up manually afterwards.
   
   
2. Drag and drop merger; identical to the previous suggestion - but instead of copy/paste the transaction is initiated by dragging structure 2 over structure 1 and e.g. holding it with an edge aligned when dropping to indicate that it is not intended to go *into* the other structure.
   
   
3. A merge option that can be called from the menu or contextual menus on case/event structures. The advantage of this would be the ability to add more complex mergers where you would want to pick frames x, y and z from structure 1 to merge with structure(s) 2 etc... This option could alternatively be combined with the other two and used as the dialog when those are initiated.