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!
Top Authors
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

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...

 

Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.

 

Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.

 

Andi_S_1-1594012798289.png

 

As reference: This is the content of Class 1

Andi_S_2-1594012849411.png

 

 

What I suggest and expect is the following:

Andi_S_3-1594013798865.png

=> The class tree shows all available methods within each single class!

bright colors: Methods that are defined in this class; pale colors: inherited methods

 

 

To make the class relation ship better visible I suggest to show the ancestor class name in brackets behind the name of the current class in the project view.

See the picture for better understanding:

 

Andi_S_0-1594038101153.png

 

When you right-click on a connector pane terminal, a context menu pops up -- but there isn't a good indication of which terminal you've clicked on:

carls___1-1593626658134.png

You could assume that selected terminal is at the top-left corner of the context menu, but (due to a bug, I'm assuming), the actually selected terminal is a few pixels down and to the right of where you clicked.

 

What if the terminal you right-clicked on got highlighted while the context menu was shown?  This would provide visual feedback of the selected terminal, giving you confidence that you clicked on the terminal you thought you clicked on (and avoid mistakes of configuring the wrong terminal).  I can't even begin to count the number of times I've set the wrong terminal to "recommended" or disconnected a different terminal than expected. Could look something like this:

carls___4-1593627315744.png

(which just piggy-backs on the appearance when you're wiring up a terminal:

carls___2-1593626739401.png)

 

Bonus points if the bug gets addressed where clicks are actually a few pixels off.

Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.

 

Proposal to make the Edit Items box longerProposal to make the Edit Items box longer

 

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

 

NXG Style Path.png

 

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

Currently, the Panel method "Convert panel to screen coordinates" works fine normally, but if the panel is inside a subpanel then it just fails without throwing an error

 

The idea is to either update this function to work properly in a subpanel, update the documentation to mention it doesn't work within a subpanel, or throw an error to indicate failure.

 

A few similar ideas have popped up, for example:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-property-subpanel-ref/idc-p/4061150#M42444

 

but that one was more generic to get the a subpanel reference from within the subpanel.

 

(My specific use-case is to create a fancy menu popup relative to the clicked item within the subpanel- basically, I need screen coordinates of the "thing" inside the subpanel, which I cannot get without coupling the subpanel VI to the main VI by providing an upstream VI reference, which I don't want to do.)

Similar to Visible items>Radix right-click menu it would be highly beneficial to have the same possibility for showing (and switching) of Representation.

 

 

ice_video_20200504-153122.gif

Please create a meaningful error message in case the application builder errors due to long path names.

 

The error below was ultimately fixed by shortening the output path in the build spec. It took me however more than half a day of fiddling around with alternative solutions to reach my end goal (https://forums.ni.com/t5/NI-Web-Technology-Lead-User/Hosting-WebVI-on-cRIO-following-KB-article/gpm-p/4061052/highlight/true#M282).

 

While explaining it to my colleague it hit me that the build output path could be too long, shortened it, built it, deployed it, and it worked.

 

 

Build error.PNG

LabVIEW 2020 allows you to remove the event property nodes shown here:

carls___0-1593446234322.pngcarls___2-1593446364647.png

It's a nice feature because these nodes are often not used and can get in the way.  However -- the process for removing them is a bit tedious: you have to either remove them all individually or size the cluster down to one and then remove through a menu.  I find that I rarely use this because, well, it just takes too long.

 

However...if you could just click on the node (it's already selectable) and then click the "delete" button on your keyboard, this process would be near-instantaneous, and I know I'd be much more likely to use it.

There are two things that bother me about the index array. I think these changes would be useful to nearly all LabVIEW users.

 

  1. The default value is not optional (for integers always zero, a very useful value) There should be a way to set the desired value if the index is out of bounds.
     

    Image 1.png

  2. There should be a way to get rather the index is out of bounds from this primitive since this has to be check anyhow to know whether to use the default value.Image 2.png should look something like this: Image 3.png

     

     

The lack of these items usually proves to generate code that looks much uglier than necessary.

Although I do not know the internal workings of this primitive it would be hard for me to believe that this would have much of a performance impact. Also, bound checking arrays is necessary for many algorithms, why do it twice? 

In LabVIEW we can specify <topvi> as a VI search path when VIs can't be found.

 

I would propose adding <project> as an option (perhaps with a subfolder by default). This would allow for new reuse patterns based on keeping libraries in the project. I expect this would make tools like GPM much easier to develop as well.

 

It could be a first step to something like node_modules in NPM or virtual environments in Python.

 

James_McN_0-1590488521270.png

 

Currently, DETT looks like this:

Taylorh140_0-1588782161680.png

But it should look like a proper profiler allowing for exploring and easily visualizing performance, threads, call stacks and memory usage at a glance (similar to this):

Taylorh140_1-1588782422432.png

 

 

 

Check out this nice readable diagram:

labels.png

Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.

 

I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either. 

Right-clicking on a VI in a project and selecting "Find -> Callers" doesn't list any .lvtest files which call the VI in question.  I think there should be a relatively easy way to find which unit tests call the VI.  I use Find -> Callers when I'm refactoring, and want to know what code might be impacted by a change.  It'd be nice to quickly find the unit tests which also call the VI.

 

Option 1) Have Find -> Callers include .lvtest files in the results alongside calling VIs.

 

Option 2) Add a separate Find -> Unit Tests

 

The function of "Compound Arithmetic" can be changed very quick and easy.

Why not use that concept for other items too?

 

Use cursor mode "Operate Value" to change function quickly.

Old: Click > Replace > Comparison Palette > Item

New: Click > Item

 

See concept screenshot for example:

Change Mode for all Items.png

 

The clicked item acts like an polymorph selector to choose from same palette or from similar items.

 

I have a 3D set of data, to which I fit a plane, and then from that plane fit a bounding box which should contain 99% of all data.

I would really like to plot both a scatter of the source data, and the surface within the same plot. Ideally the box would have transparency, but even lacking transparency it would be very convenient in visually confirming the quality of the fit. 

When I Control+Right click and drag to expand a block diagram. The expansion should NOT effect all of the unseen case frames

 

I am really tired of stuff like this happening when I expand the diagram of another frame of the same case horizontally and vertically.

 

This "Short cut" actually creates a lot more work for me as now I have to go back and clean up all the other states in my state machine that are messy now.

 

CaseCapture.PNG

 

If you change the comparison function "Is Path and Not Empty.vi" to a malleable VI, then it will be able to accept arrays of paths.

A big project can take more than 10 minutes to load, especially on an older computer.  If subVIs are missing, the Ignore Item and Ignore All buttons become available when the first VI is missing.  This can happen anytime during the loading and the process stops until the browse box is canceled and then the Ignore All button is pressed. 

 

It would be better if the Ignore All button was always available where it can be clicked at the beginning to insure the project is loaded in the expected time.

Ignore All.png