LabVIEW Idea Exchange

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].

I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.

I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.

To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?

Bob "Imperfect" Schor

Sometimes the order of the frames have to be changed in order for a VIM to work properly. It would be very useful if we could either rename the case itself or at least show the subdiagram label in the rearrange dialogue box.

Actually allow to add text in the frame case name would be much better and also help to navigate around when there is a lot of frames. All the frames are either ignored, declined and one accepted.

Usefull for debugging misfiring or overifiring frames when building a VIM with a lot of datatypes. Could simply output the frame number

Or could also output the complete frame name as a sting so that if the frame names become partially editable as suggested here, all would be coherently managed.

I'm working on a high-performance application where every bit of time counts.

LabVIEW's parallel execution helps but we are having to write individual functions in C so we can try out the AVX instructions available on modern processors.

LabVIEW recently used SSE2 so I guess the compiler supports this (well, LLVM certainly does). It would be good to have an advanced option to enable more recent updates (AVX+) to avoid going to C!

The proposal consists in being able to format the content of a string control, to allow to read more easily: INI, XML, HTML, ...

Regards.

Currently to AutoScale an axis once, you need to set the ScaleFitX/Y property to 1. However this is really just like calling a method since the value of the ScaleFit property remains whatever it was previously. As a result, I find this mechanism unintuitive and would prefer to use the invoke node to call a suitable method named ScaleFitX/Y since it is an operation that just happens at a moment in time rather than changing a property.

Current Method: Property NodeProposed Idea: Invoke Node

Provide a way to either temporarily (via key press) or permanently (via a LabVIEW option) disable the automatic creation / insertion of shift registers when adding a loop around some existing code. Much like the auto insert feedback node in cycles option.

This feature generally gets it right when dealing with references or error clusters, but other times it'll connect irrelevant data together, requiring extra effort to undo and rewire. The auto-wiring also creates weird bends when connecting the shift registers. When an unwanted shift register is then changed back to a tunnel, the bent wires remain in place.

A typical use case:

The error ring is a great and simple tool to define errors, especially when selecting "Custom Error Message" and supplying parameters from outside of the error ring.

The fact that the text search doesn't look inside the error ring makes it hard to find hard-coded error codes. 

Idea: I would love to see the search in LabVIEW also find strings inside error rings. 

PS: This idea (or inspiration for it) comes from Stefan Lemmens.

It would be nice if the Error Ring would accept enums.

So the Error Ring does not accept an enum (A). Format Into String does (B). So now we need the extra step of putting a Format Into String before the Error Ring (C).

This would be more convenient in for instance state machines (D) or functional globals with a function enum.

While on it %s on FIS also accepts Booleans. Nice to have the error ring accept them as well, just for completeness.

Title basically says it all but I'll elaborate.  With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well.  On a 4K monitor this is awful tiny.  This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees.  Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here.  Allowing for these glyphs to grow with the row height would make them appear more cohesive.  There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control.  Here is a demo from that thread:

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily.  I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop.  Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain.  Please NI add a feature allowing for larger glyphs, and I would be so happy.

DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing).  Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up.   An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open.  Many dlls have similar pointers/handles that need to be properly closed.  This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.

A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created.   That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle.   This VI would contain the code to cleanup/close the contained non-LabVIEW references.  Could have other uses, such as debugging. 

I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help.   Please consider it.

Currently, the "Tab" key is not individually mapped to an action for Block Diagram interactions; my suggestion is to use it to swap between "control", "indicator" and "constant", in the same way we already do with the options of the right-click menu "Change to Control/Indicator/Constant".

As an example, having selected a control on the BD, by just pressing "Tab" we would transform it into an indicator, a second press to a constant, and a third one would bring it back into being a control.

I understand this is a simple thing, but personally, I feel this ends up being one of the most repeated actions we end up taking as developers and I believe it would be intuitive to map it to a familiar key to many of us - tab.

Thanks all,

Cris

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

It would help if the Error Ring had an error in.

Now we always have to use a merge error (A).

This does hurt performance as well (B), as Error Cluster From Error code is always called (and isn't lightweight).

With an error in, no more merge errors (C)!

And performance gain (D) as a bonus.

Guess this input is deliberately not there? Can't wait to hear the arguments against it...

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

Originally suggested by RavensFan.

LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them. 

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.