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

When TestStand has a problem with a module, it provides a Red Exclamation mark to show detail on the problem. 

When you hove over the Red Exclamation mark, you get the details, sometimes with a file path to the detailed error log. 

 

Need a way to copy/paste the data from the details bubble. Better would be a hyperlink to the file location. 

 

Right now my workaround is: 

 - Screen capture while hovering over the red exclamation mark

 - Paste the screen capture in MS Paint

 - Re arrange the windows to show MS Paint & MS Explorer 

  - Navigate down file path to find the log file. 

 

 

mwatkins_0-1594408509848.png

 

When working on VIs that require large arrays or images for input, I often need to run a calling VI rather than the VI I'm currently working on, which involves a lot of tabbing between windows and clutter from having more open windows. I realize it is possible to set default values for controls, but I would rather avoid that as I often use optional connections to my SubVIs and therefore don't want to change default values.
In my opinion it would be useful to have the option to configure the run button to run a different VI than the currently open one, when working on VIs specifically developed to run as subVIs in the context of a higher-level caller.

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.

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

 

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

 

 

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.

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.

Windows 10 now handles long file paths although it has to be enabled with via various possible registry or group policy edits. Windows applications have to opt in. LabVIEW source code should be able to utilize long file paths.

If you've got a project open, any new VIs you create automatically get added to the project.  It'd be nice if there was a way to disable this feature.

 

I find the feature frustrating because:

- I often create new VIs that I never intend to save, just to test out some logic quickly.  However, I can't just close the VI -- I need to go and remove it from the project too -- and this also leads to a dirty dot in my project (and extra work).

- I'd prefer to have full control over which VIs get added to my projects, and where they added within a project.

- If you've got more than one project open, you have to be careful about where you press "ctrl+n" from.

- I've found myself in situations where I close a project after creating a new VI, tell LabVIEW that I don't want to save changes to the project, and by doing so inadvertently lose the code in the new VI because I'd overlooked that automatic association.

 

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

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. 

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? 

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

 

I have two arrays I'd like to pivot into an array of clusters of a particular typedef. I could index and bundle it myself, but it's just weird that I can't use this builtin function just because the typedef has an element that's an array.

 

Also, it's kinda weird that it won't take a typedef as prototype. Casting it after takes up about as much room as doing the bundle in a loop!

 

I can see some reasons that letting us pass in 2D arrays would lose the tight optimization of the original (maybe it can compile-time determine the size of the cluster elements if none of them are arrays... except that you can put in object data. I guess either that's a reference under the hood, or there's some other reason)

 

Or maybe it's that it could cause confusion between making a 1D array of clusters with 1D arrays, or making a 2D array of clusters of single elements? That seems like it could be solved either by only doing the former, or requiring a typedef in that case, to disambiguate.

If you are instantiating classes dynamically or calling VIs dynamically through VI server, you may need to include the source files under "Always Included" when creating a build. If you are dealing with a large number of files in a multi-developer environment, you might also be using an auto-populated virtual directory. The problem with this is that everything under directory will be included in the build. Say you are building a hardware abstraction layer with 100s of different instrument drivers, you will likely have all sorts of different files like programming manuals, unit tests, project files, lower level instrument libraries, and VI trees. You might not want all of these files included in the build. Some of the files might not even compile (ie. VI Trees), which will prevent you from creating a successful build. If you are instantiating the classes dynamically, all you really need to do is include the lvclass files since that will automatically bring in the dependencies for that class. You could separate these files, but it would likely be a less cohesive directory hierarchy. For example, if a developer is implementing a driver they will probably want to access the programming manual under the same directory hierarchy, while at the same time, a programming manual probably wouldn't be beneficial to a user when the build is deployed so you might not want it included.  Being able to define 1 or more file type patterns on either auto-populating virtual directories or on the build specification UI for source files, would quickly resolve this issue.

We could add a way, for example a parameter key in INI file of LabVIEW.exe, in order to run LabVIEW.exe silently, so without the splash screen and the getting started window, like a background process.

 

Example use case:

When you execute a build specification thanks to LabVIEWCLI (operation name: ExecuteBuildSpec, https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/cli_predefined_operations/), it runs LabVIEW.exe to complete the request. LabVIEW.exe is opened with the splashcreen and the main window. It's terrible, I want to use LabVIEWCLI to do some operation programmatically and silently (background mode) from my code/app.

 

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

 

When you install LabVIEW and MAX configuration support for DAQmx (and other components are the same) the NI Package Manager adds a number of other LabVIEW runtime versions to the list of dependencies.

When I install support for LabVIEW 2019, the package manager add LabVIEW 2014 and 2018 runtimes.

 

Surely this can be tidied up!  Please tidy up dependencies.

 

If I only have LabVIEW 2019 installed on my system, I shouldn't need the LabVIEW 2014 and 2018 runtimes to make a 2019 component work.

I pretty much always want VIs in a class to have the corresponding class icon template applied.

 

It'd be great if I could have this handled automatically rather than having to manually go in and click the "Apply Icon to VIs" button any time I notice that icons haven't been applied.

 

Perhaps something like:

carls___0-1590690121234.png

 

When right-clicking on a VI in a class, there's an option to "Remove From Library".  This option removes the VI from the library, but leaves the file on disk.

 

95% of the time that I'm removing a file from a class, I'd also like to delete it from disk.

 

The wording might need a bit of work, but it'd be great if there was an option to simply "Delete" or "Remove From Library and Delete".

 

(In the meantime, I'll continue to "Explore...", then "Remove From Library", then delete from my file system.)

 

carls___1-1590689294408.png