LabVIEW Idea Exchange

Community Browser
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

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):LabVIEW_2018-08-17_09-49-36.png

 

 

 

  It would be very usefull to know which VIs are still running.

   aaaa.png

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.

Autoscale Axis 1.pngCurrent Method: Property NodeAutoscale Axis 2.pngProposed Idea: Invoke Node

 

                                            "Build Path" should be Growable

 

                              something like this,

 

 

toto.png

I think it would be useful if you could double click on the items in "Referencing Items" to open the VI on the resolve conflicts dialog.

Resolve conflicts dialog.jpg

As an aside, the dialog should also remeber its last position and size. I have to expand it every time to see the full path.

 

Browsing through menus to replace a numeric conversion node is tedious.  How about allowing the selector tool to select from a pull-down menu, just like it does from an unbundle by name node?

 

Existing unbundle node behavior is shown at left.  Desired numeric conversion node behavior is to the right.

 

Quick_changing_of_numeric_comments.png

I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.

 

To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.


A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:

 

20779iD19E3A04FFDC0A31

 

In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.

Add an additional search scope in the scope dialog.  New scope will be <entire project>.  Right now the widest search scope <All VI's in Application Instance> will not reach VI's that are called by reference, but still in the project.  I have a few co-workers which are "call by reference" happy and it's a pain to track them down manually.

 

 

 

Hi,

 

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

 

Array_ordinary.png

 

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

 

Array_loop.png

 

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

 

Array_more.png

 

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

 

Cheers,

Steen

This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.

 

One example would be a "Data History Probe" that displays the history values of any data type.  I'm sure there are other good uses.

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:

 

create cluster.png

 

I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

 

Hi!

Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...

Marco

18613iCF039EA34765F743

This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.

 

To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.

 

Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.

 

My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.

 

Typical phone exchange yesterday:

 

me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

        (..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."

 

End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.

 

While gazillions (Smiley Very Happy) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.

 

I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".

 

 

Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. Smiley Very Happy

The idea is to know the result of the tunnel mode condition, in this case, it is to know if any element has been indexed.

 

whileconditional.png

 

This publication is motivated from the following discussion: Tunnel Mode Conditional .... output condition (by @ouadji)

 

Regards.

Here's how we currently make cluster element labels appear, and a proposed idea for improvement.

ClusterLabels.png

I envision a structure much like a case structure, in which you select your event for evaluating the code inside the structure and the values become constants at the node. The interior would allow code that may normally not be able to run on the host for example, on fpga it might allow the use of doubles and strings and resized arrays, because it isn't actually going to be executed on the host just evaluated and stored as a constant. This would allow for more configuration for fpga and even have some benefits at the traditional desktop environment. For example you could set the structure to evaluate on app build and produce a string constant that is the build date so the build date could be shown on UI to help distinguish builds. 

image.png

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 problem that height of local variable is 17 pix, and terminal - 16 pix, but distance between terminals in unbundle function is 15 pix.

As result - aligning to vertical compress caused steps in wires:

 

Screenshot.png

 

Right nowterminals/local variables should be slighly overlapped for "step edge free" wiring.

Please synchronize size of these icons with distance between terminals (to 16 pixels - seems to be ideal size)

 

Not sure if it was already in Idea Exchange or not.

 

Andrey.

 

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png