LabVIEW Idea Exchange

A new function that indexes the last element of an array would spare some place on the diagram or avoid to use a subVI !

Or the Index Array function might be enhanced (First, specified Index and Last).

It would be nice, if you could resize a structure to a minimum (a small padding should be left over) with simply double-klicking on these small blue "resize-squares". It should function with every "resize-square".

Comments for code explanation of the block diagram can be added using the text labeling tool but they can occupy too much space.  Many LabVIEW examples use an alternative of placing a marker label such as "1", "2", etc at desired locations which refer the viewer to another comment location on the block diagram where expanded corresponding text is displayed.  This means though that diagram scrolling must be done to see the explanation for the comment.  How about a Help Hint type of "hot" label that when hovered over pops up a short comment and when clicked on shows a more detailed comment.  Similar to the front panel's Description and Tip but available at edit time and maybe not requiring a right click to see the full comment description - just a left click.

As LabVIEW evolves more and more, the compiler takes over an awful lot of code optimisation for us.  This leads us to situations where relatively large and important pieces of code can be evaluated at compile time and constant folded which can greatly aid execution speed.  This is good.

Constant folding can be a great aid when programming but at the moment, it's usage is a bit "hit and miss" due to the opaqueness of the process.  We already have constant folding highlighting, which really helps things (even if the feedback is sometimes very hard to understand).  But this doesn't always give us enough feedback.

What I would like is the option to declare a portion of code as "Requires constant folding" (like a "Precompile" structure).  In this way, I can, as a programmer, designate some code which is meant to be evaluated at compile time.  If the compiler is unable to constant fold this code, then the VI should be broken.  My motivations are three-fold.

1. Sometimes we want to specifically make use of the constant folding capabilities of the compiler, but a small change can result in the code no longer being constant folded.  I would like explicit feedback when code I want constant folded is not constant foldable.
2. I have no idea whether code complexity has an effect on the ability to constant fold.  Other compiler optimisations (Like unbundle-unbundle inplaceness) are dependent on code complexity.  Explicit declaration is not code complexity dependent.
3. When looking at FPGA designs, the ability to perform constant folding of data otherwise requiring resources or affecting performance is very powerful.  In such a "Constant folding" code, we could also allow mathematical functions to be used which are otherwise not supported on the target (max/min of an array in a timed loop for example), or creating default data for an array (to be used as Block RAM) based on an existing equation where constants are defined as DBL.

One example of FPGA code is automatic latency balancing of several parameter pathways into a process where the code accepts abstract parameter objects whose latency is queried via a dynamic dispatch VI which simply returns a constant.  I use dependency injection to tell the sub-VIs which communication pathways they are being given and they can then query the latency and do some static timing calculations for the delays required on different pathways.  Tests have shown that this is constant folded and that it is thus possible to write very robust FPGA code which auto-adjusts request indices for parameters in multiplexed code.  At the moment, things seem to work but the ability to specifically designate such code as being constant folded would be welcome to make sure I don't accidentally produce a version which doesn't actually return a constant (and my compiles fail, I get timing errors, or just over-use resources)....  In the code below, all of the code circled in blue is constant-folded when compiling the FPGA code.  In the sub-VIs I have to do some awkward calculations because certain functioanlity is not available on FPGA.  By defining this code as requiring explicit constant folding, I could theoretically utilise the full palette of LV functions and also be guaranteed a compile error (LabVIEW error, not Xilinx) if the code thus designated can not be constant folded.

So in a way, it's similar to the In place element structure which, when all goes well, should not be needed but there are cases (I've run into some myself) where either small changes in code can make the desired operation impossible or where the code complexity can cause the optimisation to not be performed.  As such, it is still required at times to explicitly designate some code paths as being In-Place.  I would like to have the same functionality for "Constant folding".

Currently, it takes LabVIEW user the same amount of time to find and select commonly used functions as ones they never touch. The function palette requires the user to interface with all of the hundreds of functions, including the vast majority which they do not use on a regular basis to select ones they use often. If, for some reason, the user was working with the "NI435X configure port in.vi" regularly, it would take clicking through 7 menus every time they wanted to drop the block. It also makes it very difficult to find, as there are 7 levels of places the user could go wrong trying to find it.  

Example:

Many other programs, particularly CAD and CAM, have minimized this difficulty by allowing the user to add in customizable toolbars to his GUI. They can be either floating or attached as well. For instance, Solidworks allows the user to create custom interfaces which can look like this: 

:

A large portion of the regularly used functions are all displayed at once on the customized toolbars on the top. For regularly used (or self explanatory) functions, like "multiply" in LabVIEW, no space is wasted in the description area, and the icons can be scaled down quite a bit. For multiply, it takes the click count from 4 to 1 (right click, programming, numeric, multiply to simply a drag and drop). Much more time can be spent coding, instead of looking for blocks.

Furthermore, there are many ways to customize the Solidworks GUI, which can be seen below. The first window allows the user to select which toolbars are on the screen, as well as set hotkeys for any action in the program, also a great feature. The second window (from right clicking the toolbar) allows the user to select which icons in each toolbar are actually on the screen. The toolbars can also be dragged to various locations, be seen with -or without- large icons and text, and be floating or attached, all great features. 

.

I would love to see a labview that looked like this:

Also, Im not suggesting getting rid of the functions palette, only allowing the user to place SMALL (preferribly smaller than on the FP), perminent icons where they need them instead of only using the rather unweildy functions palette for everything.

For reference, here is a good article which covers the Solidworks Command Manager:

http://www.solidmuse.com/2008/01/customizing-the-solidworks-2008-command-manager/

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

Today, the management of error codes is a little bit complicated. (Error code file to include in executable properties ... )

It could be intersting to add a new entry to a project which could list all custom errors only available to the project.

This file or project property could be associated with the project as a source code !

How many time you'll get an old application ... without all files ... And error code file is a source file. So the error code file should be located near the project ...

Or best inside the project !

The best way to manage the custom errors would be to edit them in the project properties like "conditionnal disable symbols".

Simplifying the error code management will reduce the none managed errors ( The famous 488 error !!!! which i hate ! )

Having a complete API for zip file

Currently it has :
- New zip file
- Add a file to zip file
- Close zip file and add a comment
- unzip the zip file to a folder

This API is not quite complete.

Example of use of ZIP files: In a data streaming application, you want to make an archive of recordings files. The data files average 500 MB Once compressed, they do more substantive than 50MB. You create an interface to assist the user in steps of compression. Once compressed, you want to propose an interface for retrieving compressed recordings.

The ideal is to list the files and clarify some information, such as track number, recording time and a few other indicators related to data.

But to do that, we 'could' use two ways:
- The properties of the zip file.
- An additional file that would read that to see them.

Several problems arise:
- It is not possible to read the commentary added with the close function.
- It is not possible to edit the commentary added with the close function.
- It is not possible to decompress a single file.
In the example, if we unpack all files to read properties, it'll take time and a lot of CPU resources.

It would require full management functions:
- New file
- Close file
- Add a comment
- Read the comment
- Erase the comment
- Add a file
- Delete a file
- List all file (with or without a mask)
- Uncompress a zipped file to disk
- Uncompress a zipped file to memory

- compress and uncompress a string in memory (usefull to optimise the network data flow)

In the ideal case, a zip file should be considered a folder. So we have all classical file functionality to manage it.

The number of parallel Instance is currently capped at 64, independent of hardware. This limit should be raised.

First Reason: Since even 64 bit Windows 7 supports up to 256 cores, it would be reasonable to raise that limit to 256.

(Even the next version of windows mobile (8) will support 64 cores. (Mobile! On a Phone! 🐵. Obviously the upcoming hardware is fast moving in that direction.)

Second Rason: Sometimes it is useful to generate many instances, even if we have fewer cores available, for example maintain individual data in a large number of identical reentrant subVIs. (Such an usage example where we want many instances even on a single core machine can be found here)

Idea: Raise the max number of parallel Instances of a parallel FOR loop to 256.