LabVIEW Idea Exchange

The "Save As" dialog does remember the last selection (this is nice). But sometime when going from "Rename" to any "Copy" operation there are one too many click.

This is what you have to do if you want to go from "Rename" to "Copy>>Open additional copy".

Instead this is what you should be able to do.

This is fairly minor (and a low hanging fruit) but this will improve usability.

Provide a new command line option to show the block diagram of a VI in addition to and above the front panel automatically. I almost always open VIs in my project folder from a terminal and most research and development work is on the code. See current arguments here: https://www.ni.com/docs/en-US/bundle/labview/page/lvhowto/lv_defined_args.html

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".

Here is a small tweak that would save me a lot of development time (when added up). When I create a new cluster for a typedef or on a front panel, the cluster shell should default to the Arrange Vertically autosizing format. This is already the case for new class clusters, and it is really nice to use! It is a pain to repeatedly configure this setting after dragging a new control type or types into the cluster and have it mostly obscured behind the cluster shell.

It's a small improvement, but these small improvements really add up or time!

I often find myself switching between different machines and different versions of LabVIEW and one thing always bugs me.  Sometimes I have to work on a customer's machine with their (almost always) awful settings.  The settings for the development environment are always different to what I want no matter what I do.  It's a pain to have to keep all up to date.

While I know others have suggested moving the ini file to the user folder or allowing us to choose the ini file, I would like to go a step further and allow us to enter a web URL to access our ini files.  This way I can work effeciently on anyone's development computer with minimal effort and we can even share our settings if we want to.  We could have community INI files for others to use.

We experience two use cases that is quite hard to complete 100% succesfully:

1) When we work several developers on a project we need to have identical development environments on our computers or else we get "dirty dots" on our VIs when another developer opens them from SCC. The development environment consists of at least LabVIEW version, modules, tool-kits, device drivers, patches, service packs, maybe TestStand, and maybe third-party tools as well.

2) If we need to recreate a particular development environment because a customer wants an update to some existing application.

The first one we try as hard as we can to achieve with lists "handed around", but it's almost impossible to extract all the version information from the installed environment (you have to look many places and filter each list manually), so it's extremely easy to miss something. The second one can be achieved with images on virtual machines, but sometimes VMs can't be used due to hardware or IO limitations, legal rights and what have you.

So I suggest some form of tool that lets you export an .msi that you can run on another machine, that tells you what to install to replicate the dev environment the .msi was created with:

The tool could be available from the various Tools-menus, and maybe from the MAX, from Start->Programs->National Instruments etc. It could open up a configuration dialog like this:

The install script (.msi or similar) shouldn't contain any applications itself, but would just be a guide to get the proper tools installed - you must have access to the install media and activation codes yourself, but you would be told what to install, and the script would be able to verify that the installer you're pointing it at really installs the correct version. It should be possible to skip steps during the install guide process, and it would be great if the installer would also be able to handle already installed versions (both the correct and the wrong versions = different actions available).

Cheers,

Steen