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

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.

Instead of right click on the Array to Cluster for Cluster Size, double click will be ease for the programmer to select the size of cluster

 

Double click should enable this pop up.

ClusterSize.png

For all of us not running an english OS but want to install plain english versions of NI products:

Please give us an option or a documented method to install LabVIEW and  MAX and driver, etc. in plain english.

While it is possible to install LabVIEW in ENG, the MAX and the driver installer lookup the OS language and install the localized versions Smiley Sad   (just tried with a new PC, W10 and LV2018 full dev suite, even set my language setting to ENG, however I have to install the localized W10)  That is not helpfull if you want to look up the big commuinty help or knowledge base entries and can result in 'funny' error messages.

 

For the driver DVD I think I found a hack in the setup.ini

[Localization]
Languages=9,7,12,17,18,2052
#ForceLanguage = 9
CustomRes0009=SupportFiles\resourceEng.dll
CustomRes0007=SupportFiles\resourceDeu.dll
CustomRes0012=SupportFiles\resourceFra.dll
CustomRes0017=SupportFiles\resourceJpn.dll
CustomRes0018=SupportFiles\resourceKor.dll
CustomRes2052=SupportFiles\resourceChs.dll
StandardRes0007=SupportFiles\niresdeu.dll
...

by uncommenting the red part. But editing the setup.ini ??

OK, in this case the hint was there (or forgotten to remove Smiley Very Happy)

The actual suite installer comes with a .xml  configuration file where that hint was missing or overseen.

 

I suggest something like:

 

Installer found local language version: <OsLang> ,

Install (where possible) in language: <ListOfSupportedLanguages>

 

That setting is hopefully stored for future automatic updates Smiley Wink

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

Enum in Error Ring.PNG

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.

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

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

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

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

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

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

 

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.

 

 

Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:

 

LabVIEW_2018-11-05_09-16-13.pngThe Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>

 

LabVIEW_2018-11-05_09-26-34.pngUnhelpful context help.

 

Text ring would have the least impact on existing primatives: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-Type-Function-needs-another-return-for-an-empty-...

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

 

User Event Refnum.PNG

 

Create User Event function

Output of Create User Event function should be name of the input instead of "user event out"

This will save time to rename each output indicator as input. 

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.

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.

 

Right now the search window results have 3 columns, a check box, a number, and a string containing 4 pieces of info (the vi name, window type, object type and element type).

 

My idea is to reformat the last column into 4 columns.  The results would be the exact same, however they would be in 4 columns.  Then make the multi-column list box sort-able.  So if I click the list on the top of window type, then all the diagrams would be sorted together and all the panels would be together.

 

The most useful part of this for me would be sorting by object type.  If I look for something very common and get say 500 hits in my project, sorting by object type would be a big help.  Now I can quickly locate the group of hits for, like, an "EnumConstant", or whatever type of object I'm interested in.  Now I don't have to slowly look though the whole list looking for the object types I'm interested in.

Wouldn't it be great if you could list only the recent files opened while in a particular project? I often bounce from one project to another, closing the projects in between.  Thus, I often would like to be able to view only the file recently opened from within a

the project I am working on. Adding a "Recent Files (by project)" to the Getting Started window would be valuable as well.

 

2018-12-07 view recent files by project.png

 

If creating a reference to a .Net control you will observe that is reference type of ActiveXContainer is created which is sometimes confusing at a first sight.

 Container.JPG

Please introduce a .NetContainer (at least cosmetically at block diagram) for a better overview. If you are doing so, you could change as well the color of the ActiveX container with respect to the .Net container on the block diagram. If you have to change the programming interface, it would be much easier to spot where you have to do so.

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