NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

For FPGA programming, sometimes I want a smaller representation of the loop iteration terminal on the for loop mostly just to squeeze every last gate out of the chip. Other times I want the integer to be unsigned or larger to prevent saturation.

Build Specification Version Information

Status: New
by Member hfettig on ‎11-04-2009 12:58 PM

In the Build Specifications under Version Information one has the option of setting the Version Number of the build. Ther Version Number is of the form Major.Minor.Fix.Build.

 

There is an option to Auto Increment the Version Number. If this is selected the Build component of the Version Number is automatically incremented every time the specification is built.

I always use this setting since I can thereby tell the difference between builds. The major annoyance here is that although only the Build component is automatically updated all four controls are disabled and grayed when Auto Increment is selected. That means that every time I want to change the Major, Minor, or Fix part of the Version Number I have to uncheck Auto Increment, make my changes, and then re-check Auto Increment. More than once I have forgotton to re-check Auto Increment, which then screws  up my numbering scheme.

 

Idea: When Auto Increment is selected for the Version Number, only disable and gray out  the Build control. Leave the Major, Minor, and Fix controls enabled.

I wouldn't call it common knowledge, but it's certainly not unknown that there are LabVIEW callback VIs that are invoked if present when certain development environment events happen. With the growing prominance of scripting and the increasing ability to develop custom tools to inhance development, I suggest a more flexible approach to these callbacks. Right now, if you want to use these VIs you have to be careful that you don't overwrite the existing VI (if there is one), or you have to manually go into the VI and drop your subVI that you want to run, within the specific callback VI. It would be nice if there was some tool within LabVIEW that allowed you to select the VIs you would like to run on certain LV Development Environment events, and then the paths to those VIs would be fed into the callback function VI to be called dynamically. While us developers could create something like this on our own, a standardized template for a more flexible callback would be nice. This would ensure the developer could create VIs to, say, run on LabVIEW startup but never have to muck with the actual lv_init.vi VI, worry about what's already in the VI and overwriting it, etc. They would just have to configure another path to a VI for the lv_init VI to call. If anyone has a more flexible idea, please feel free to add to this.

A queue message is basically the same thing as an event; a notifier notification is very similar.

 

I suggest allowing us to handle queues and notifiers with the same Event structure as User Events and Front Panel Events.

Status: Duplicate

Free Label Default Colors

Status: New
by Member 10Things_Rob on ‎04-21-2010 10:54 AM

I find it a problem that free labels by default have the same color as native functions; there is no visual distinction in meaning. Hence I always have to change my free label colors... and I expect a lot of people use color on their free labels to mean different things.

 

 

*** SUGGESTION/IDEA ***

I suggest allowing the user to set the default FG/BG color of free labels in the LabVIEW Options.

Perhaps a different setting for Front Panels and Block Diagrams would be appropriate; that also would eliminate the "use transparent free labels" option from the Block Diagram options.

 

 

*** Other Train of Thought: not a full idea yet ***

As an interesting follow-up to consider I also suggest considering the use cases for free labels. Perhaps there should be a way for the user to create different types of free labels and assign them default colors; if that were the case it would be cool to be able to seach for "High-Priority Labels" in all opan VIs....

Here's a problem a lot of people have encountered.

 

You want to implement a nice UI and decide to do some fancy UI programming with mouse actions being linked to certaina ctions on the FP.  Nice and fancy until the mouse cursor leaves the bounds of the front panel.  If I have a mouse action on the FP requiring me to hold the mouse button down and I then move out of the FP and release the button, LV does NOT realise that the mouse button has been released and the code int he FP still reacts to the currently un-pressed mouse button.

 

This is annoying and has been around for longer than I can remember.  I recall hearing that the proper implementation is not trivial, but there must be some way around this.  Please?

 

Shane

Version independent source code saves

Status: New
by Active Participant ErnieH on ‎10-18-2010 08:54 AM

Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.

Easier access to terminals and settings in loop structures

Status: New
by Active Participant SteenSchmidt ‎03-08-2013 02:12 PM - edited ‎03-08-2013 02:16 PM

Hi,

 

I'm growing increasingly tired og all the clicking in the BD to configure all our nodes and structures, and am searching for better ways the IDE could help us get (or get rid of) the items or settings we want. One category of configuration is our structures, for instance the For-, While-, and Timed loops. So this idea covers a couple of changes to those structures:

 

1) I suggest it should be possible to hide the iterator terminal in loop structures. There's no law that says it must remain present, in case we don't need it.

2) I suggest two easy ways to hide optional terminals (the iterator terminal in general and the conditional terminal in For-loops), namely selecting a terminal and pressing DELETE should hide the terminal, and dragging a terminal outside the structure and letting go of it should also hide it;

 

DragTermsOut.png

 

3) Making a terminal visible again should also be simpler than right-clicking and enabling the correct option in the context menu (that option should still exist of course, as it remains a standard way to find stuff if you don't know a better way). I suggest one or more "selection areas" be defined along the border of the structure, which upon mouse entry would popup a terminal you could drag back and drop into the structure. In a For-loop such a "selection area" could be the lower right corner, of course not overlapping the resize handle:

 

ForLoopSensitiveArea.png

 

When you move your mouse into such an area a selection menu should appear, from which you can drag stuff or enable a setting or whatever:

 

ForLoopSensitiveAreaSelected.png

 

ForLoopSensitiveAreaDrag.png

 

The "selection area" should be relatively small so you don't activate it all the time by accident, but large enough that it's easy to hit. You should also be able to dismiss the popup with ESC or CTRL in case you wanted to do something else in that area of the structure.

 

Isn't this easier than clicking and navigating into nested menus all the time? Even the "Visible" context menu could be such a hover and enable/disable bubble...

 

Cheers,

Steen

Faster search palletes

Status: New
by Member craigp on ‎04-26-2011 10:56 AM

I'd love it if the LabVIEW developers optimized the search speed for searching pallettes for VIs.  When I hit the Search button on the Controls pallette, it can take 30 seconds or more before I can search as it says "Populating List...Please Wait."  It would be great if LabVIEW could populate the list as a background task sometime after startup such that when we need this function it would be ready to go without waiting.

 

 

I would like it easier to create labels on wires.

Status: New
by Member MikaelH on ‎11-17-2011 09:24 PM

To create a label for a wire I like to select it and then just start typing.

Instead of having to right click and make the label visible first.

//Mike

There are some dialog boxes in LabVIEW that I think need to have a "set as defaults" option available.  As an example, there are a lot of form fields when building installers for my applications that need to always be the same (or almost always).  In particular the "Version Information" section:

Untitled picture.png

 

This is something that is rather minor.  However, as a day-to-day LabVIEW developers, filling these fields out over-and-over again has gotten old.  Thanks for your consideration.

Selectable Class Data Member Scope

Status: New
by Trusted Enthusiast on ‎10-12-2010 07:39 PM

Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.

 

Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.

 

I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:

 

  1. Obviates all the piddly accessors clogging your project tree and SCC server
  2. Allows quick visual recognition that a data member is being read/written directly (no data transformations were snuck into the accessor)
  3. Cleaner interface for callers of the class using the Bundle/Unbundle
  4. Best of all, saves considerable development and maintenance cost
Here's an example of what the Data Member Scope Configuration screen might look like:
 
ClassMemberScope.png
 
Note that clusters can have "Custom" scope, which means the cluster's elements have different scopes. Also note that when a cluster's scope is set explicitly, it's members inherit the same scope and cannot be set (note how 'x' and 'y' are greyed under 'Center of Mass'). The default behavior (which is equivalent to today's default scope) is for 'Class Data Cluster' to be 'Private' with all descendants greyed.
This Idea is one product of a discussion which has taken several routes.

Make inheritance graphically setable

Status: Duplicate
by Active Participant F._Schubert on ‎10-12-2010 06:25 PM

LabVIEW has a success story due to it's ability to program graphically. But the new LVOOP features still lacks the graphical touch. On the other hand, the text based SW is catching up with graphical modelling concepts as uml.

 

So instead of a simple config editor to set the inheritance, I request to have this completly graphical.

It's THE main feature of LabVIEW to do things graphically, so why fall behind this standard? No, not this tree control, but draw a wire to the parent, uml is already showing the way.

Status: Duplicate

Add an intlligent select all feature

Status: New
by Trusted Enthusiast on ‎06-27-2012 10:28 AM

Create a shortcut or a series of shortcuts to all a "Select All" on specific types of elements on the block diagram. For example, "Select All Controls", "Select all Containing Structures" or "Select all wires within area". You can do and select and drag now but often this selects other items within the selection area. This is simply a shortcut for selecting multiple items and allow some level of filtering on the selection.

Project Based Environment

Status: New
by Member Marc Blumentritt on ‎10-19-2009 05:07 AM

Hi,

 

there is an idea about making labview.ini and other user configs to the corresponding user folder .

 

I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.

 

E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).

 

If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).

 

Regards,

Marc

Create value property linked to type def

Status: New
by Member jacemdom on ‎10-17-2009 12:35 PM

Link the control, indicator or constant to the type def when creating it from the contextual menu of the value property node.

Change CRLF Mode on TCP/IP Read

Status: New
by Member GRNDRCHR on ‎04-07-2010 03:06 AM
It would be nice to see a string terminal added to the TCP/IP function so that you could choose which character set you would like the TCP/IP read to look for before ending its read.  Then instead of having the CRLF mode it would be called Character Search or something that would appropriately fit.  I have run into this being an issue when I have used a serial to TCP/IP converter because not all serial equipment sends a CRLF character such as Alicat Scientific Flow Meters and Controllers.  This came about because the converter does not buffer the data once a TCP/IP command is sent making it hard to build a loop that builds up a string of data one character at a time by setting the read byte count to one then looking for the control character and ending the loop when it is found.  This is because once a single byte read command is issued the device releases it's entire buffer and every thing after the first byte of data is lost.  Perhaps I have overlooked something. If I have please do not hesitate to let me know.
When you select "Advanced->Customize..." on a control you can't Select a second control and do the same. 

This way it's a pain to "copy past" image from one to the other control. It should be possible to customize two controls at a time

  

EditTwoControls.png

VI Viewer that does not require a license

Status: Duplicate
by Member JoeC on ‎06-21-2012 02:12 PM

Have you ever found yourself wondering what was going on with a sub-VI on a deployment system, but could not view what was going on with the VI without going to your development system?  How about an installation that allows someone to view a VI front panel and block diagram that is not locked or password protected?

Status: Duplicate

The Report Generation Toolkit does not allow you to delete a worksheet (or anything as far as I can tell). I realize that it is a "generation" toolkit, but it does have modification functions such as being able to overwrite a cell. Deletion is a modification function of sorts and it seems like it is a pretty basic function. Also, figuring out how to open an existing file is not obvious. You have to use the New Report function. It turns out that you can use an existing file as the "template", but that doesn't show up in the documentation. Rename the function as New/Open, something similiar to the file I/O Open/Create functions and at least add a  note to the help file.

Latest LabVIEW Idea Exchange Blog Posts
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 Kudoed Authors
User Kudos Count
95
71
47
46
44
Idea Statuses