Home > Community > 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

 

  • I like to make plugin tools that work on items in the project e.g. Libraries/Classes.
  • I like implementing these plugins using the Quick Drop plugin framework.
  • And I normally always work with the LabVIEW Project in my standard workflow. 

 

 

If I want to act on a Library, obviously I can just open a Member VI and get a reference to the Parent Library to do this.

However, I feel it would be more natural to Quick Drop on the Library in the Project itself!!

I also feel that it would be faster...

...And isn't that what Quick Drop was invented for?

 

I don't know if native options would ever exist, I am looking to call my own shortcuts - but there is alot of scope to implement custom plugins.

I have only given one example above.

 

Cheers

 

-JG 

 

Quick Drop on Project Window.png 

We can right click and insert a VI using a right click. However it would be nice if we could hover over a wire and use Ctrl-V to paste a VI and have it get wired automatically. Granted it may not be able to wire everything but it could be fairly intelligent and wire up what it can.

A few special functions are incorrectly named in the LabVIEW documentation.

- the incomplete gamma function VI returns the regularized lower incomplete gamma function (as is the case in LabWindows/CVI).

- the incomplete beta function VI returns the regularized incomplete beta function.

 

Suggestion: change the description (and name) of these VIs to reflect their common mathematical definition.

 

Valid at least until LabVIEW 2013 SP1.

Allow multiple event callback VIs

Status: New
by Active Participant David_L on ‎08-16-2011 09:42 AM

As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI.  The only problem is that there can only be one Callback VI per LabVIEW installation.  My suggestion is to allow more than one callback VI to be called when the events happen.  This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.  

 

This is similar to my previous idea, but generalized for all the callback VIs.   

I would like a better way to clear the list of recent files and recent projects in LabView.  It is often disireable to clear the history when changing to a different project or a different user.   Currently the user must close LV, edit the .ini file and restart LV.  I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.

The addition (in 2013) of the ability to use tags in the directory names of the builders struck me as really useful - normally I build to a ...\MYPROJ\... set of directories (each of the ) then rename ..\MYPROJ\... to ...\MYPROJ x.x.x.x\.... as required. When I read of the ability to use [VersionNumber] and [ProductVersion] tags I thought wahooh - at last an automated mechanism. However when I played with the tags it became clear that each builder (app; Installer; Source) used its own version and did not have access to any other builds' version info. Hence I could not use a single version in all builders. Especially as the Product version is one digit shorter than the others.

Given the principle that the builds now accept tags (akin to macros in my opinion) it would be really useful to have a global version tag (that could be set automatically or manually as present versions) accessible from all builders  in a project for use in directory name creation and ---- to go even further ---- to have this global version available from inside the project VIs so I can use it in my window titles and About boxes (I currently use App Info VIs to get a version, date etc to do this).

asigning plot data on the right Y axis

Status: New
by Member qing_shan61 on ‎01-30-2012 09:56 AM

Would it be good, on the Graph Properties page, Plot tag, one can set up the Y-scale to left or right? Good idea? Give this idea a Kudos!

 

At present, one can achieve a two Y plot by: right click the Y axis, Duplicate Scale, Swap Side, and often confused with which plot is associated with which data set.  A cleaver package like LabVIEW should not need to do this.  Just look at what Mathcad does.

paste text without format

Status: New
by Member BVSmith on ‎09-04-2013 03:48 PM

I see that LV 2012 uses the original text font/size/style when pasting text from the clipboard.

LV 2011 and earlier didn't.  They just pasted the text using the font/etc of the object it is pasted into.

 

Is there a way to disable this "feature" or should I report it as a bug?

I didn't turn up anything when I searched for this.

Rotate Block Diagram Icons

Status: New
by Member JoshuaZ on ‎04-29-2010 03:17 PM
I would like a way to rotate the block diagram icons (like +, X, etc.). right now LabView forces me to build programs from left to right. I don't always want to make a bunch of subVIs just to make it easy to fit on one screen view. If it was possible to rotate block diagram stuff 90 degrees (45 deg. not necessary) I could then connect my loop counters (i) easily to a sink that is controlled by what loop I'm on and other applications wouldn't become so large (left to right).
[FORUM: The below message is a copy of what I submitted on NI's feature request page, but I figured I would see if people here think its a good idea?!!]

Hi!

I would like something similar to this:

In Multisim I can drop a "comment" on the schematic block diagram. This will allow me to type in a (lengthy) comment and when I click ok it drops a pin icon on the schematic page.

To show the comment, mouse over it or right click the pin and select "show" which will display comment field regardless of mouse-over status.

This feature would be great to drop in comments in dense sections of complicated code, such as nested loops where the inner loop/case might take up very little screen area, but it would allow me to do this without taking up much diagram space (except for when the comment is being displayed, at which point it should behave as a "on top/front" text field, covering code below it.).

I for one would use this A LOT when writing code, but I can hardly claim that it is more than a trivial necessity....?

Wen LabVIEW starts it tries to not do everything immediately so that the startup can be as fast as possible, this is great.

 

However, one of the things it appears to lazy-load is the shortcut (i.e. right-click) menu. Very often I will have had LabVIEW open for some reasonable period of time (minutes, hours etc) and then I will need to do an operation that is easiest via the shortcut menu. Currently this causes LabVIEW to load all the relevant menu options the first time, and it can take a few seconds even on a fast PC. Subsequent operations are virtually instantaneous. 

 

I propose that the short-cut menu options get loaded in the background automatically some time after LabVIEW has started. This could be something like a minute or so and I would probably never notice it.

 

Note I use the word "load", I do not really know what is going on behind the scenes, but from the sluggish nature I presume there is some disk access going on the first time it is created. Substitute the word "load" word with whatever feels more appropriate (initialise?).

Add empty reference containers to the front panel

Status: New
by Active Participant Daklu Active Participant on ‎09-19-2010 01:10 PM

When working on a front panel you can drop a typeless array and add or remove data types from it.  If the array isn't typed, the vi won't compile.  (Broken run arrow.)

 

I'd like to see this behavior extended to other constructs that contain type information:  queues, notifiers, user events, and DVRs come to mind immediately but there may be others.  For me the lack of this ability is most noticable when I'm creating new classes.  I'll be trying to set up the class definition (.ctl) but if it contains any of those data types I have to open a block diagram, drop the create prim, and create a control on the output terminal.  It's inconvenient to have to do this with any vi, but moreso with ctl files since they don't have a block diagram associated with them.

 

The property node will be executed in top to bottom sequence. Changing the sequence of the property node is difficult now. In the example shown, reordering from Available sequence to expected sequence will more steps.
Proposed Idea: There should be an option of reordering the sequence on the right click menu of property node as we have in case structure (rearrange cases) 

 

The property node will be executed in top to bottom sequence. Changing the sequence of the property node is difficult now. In the example shown, reordering from Available sequence to expected sequence will more steps.

 

24278i34BF0287468F2376

 

 

 


Proposed Idea: There should be an option of reordering the sequence on the right click menu of property node as we have in case structure (rearrange cases) 

 

Attached the images also.

Distribute objects according to the size of the FP

Status: New
by Active Participant ramses64 ‎08-05-2011 12:50 AM - edited ‎08-05-2011 12:51 AM

Hi all,

In a perfect world,it sould be possible to distribute items on the front panel according to the height//width of the front panel !

 

Today, when I create a dialog box, I place the controls on the front panel, close an eye move away from my screen, then watch if my buttons are well centered.

 

Tomorrow, wen I'll create a dialog box, I will place my controls on the front pannel, horizontally distribute them, and click on the new NI button to dispatch them accordingly to the current FP size !

 

 

File dependent persistent file paths

Status: New
by Member CarstenPXI on ‎09-15-2010 09:48 AM

Currently, LabVIEW uses standard Windows "last path" mechanism to create the default persistent path when loading or saving files.

 

I would like to have this be made more user friendly, by having file specific persistent paths remembered by LabVIEW.  For example, individual persistent paths for Projects, VI's, Controls, etc.  This saves time navigating the file hiearchy when the file type has changed. 

 

Yes Windows has a Recent Documents folder in the file dialog, but it often is sluggish loading.  In one application that we write, we have six different persistent paths to make life easier for the end user.

 

Carsten Thomsen

I've just run into a "feature" of the LV2009 Parallel For Loops which is a bit of a nuisance!  The number of loop instances is determined by two values: 1) the number of instances in the Configure Iteration Parallelism dialog, and 2) the number wired to the P terminal of the loop.  It turns out that the number of instances created is the smaller of these two.

The nuisance is that if I wire the number of processors from CPU Information to P (as recommended) then when my new 16-core machine arrives (I wish!) I don't get that benefit unless the dialog value is also >= 16.  And the 64-core machine that arrives next requires the dialog value to be reset in every Parallel For Loop - or I set it to be some unreasonably large number now, and therefore it's pretty much meaningless.

 

My suggestion is that the default number of instances set in the dialog is "Maximum" - i.e. it will use the maximum number of processors available.  It should still be able to be set lower should the programmer wish to restrict the number below that.  Then the default case works transparently as the programmer would usually want without needing to wire from CPU Information, and there are no surprises down the track when loops don't speed up on a new machine as expected.

FXP conversion should accept arrays

Status: Duplicate
by Active Participant dan_u ‎07-19-2012 06:25 AM - edited ‎07-19-2012 06:28 AM

Basically all numeric conversions accept arrays or other data types like clusters, but "to Fixed-Point" conversion doesn't.

Strangely enough, implicit conversion (wiring a DBL array to a FXP array indicator for instance) works.

 

See image.

 

FXP-Conversion.png

 

"To Fixed-Point" should be more polymorphic, it should accept arrays (1D, 2D, nD).

 

Change to Array on right click

Status: Duplicate
by Member CrystalTech on ‎04-22-2014 07:40 PM

Add "Change to Array" feature on Right Click for a control or constant.

 

So many times I have to select the control (or constant), then select an array, then place the control into the array.

On a right click, the panel with a 'Change to Array' selection would be a real time saver.

I didn't find anything that listed this feature, but I figure this would have already been a feature if it had been posted.

Change to Array.gif

Array Reshape on the In Place Element Structure

Status: New
by Active Participant GregS on ‎04-13-2010 09:40 PM

There are many array functions that don't need to depend on the dimensionality of the array - for example most of those in the "Probability & Statistics" menu (Mean, Median, Std Deviation etc) and some in the Signal Operation (like Scale, Normalize).  But if I want to use one on a 3D array, I must first make a copy by reshaping to a 1D array, which can be very memory-expensive.  I'd like a node on the "In Place Element Structure" which accepts an array of any dimension, and makes the data available as a 1D array of that type.

 

I've suggested a similar idea before here, but perhaps I made it too complicated to receive any comments!  I keep running into this problem, so lets try again.  Smiley Happy

 

I thought a little bit about how this suggestion should be called.  I also feel that NI HAS improved in this area a bit in the last few years but regardless....

 

We all know that NI sells LV as being "Easy to use" or that people can "rapidly and cost-effectively interface with measurement and control hardware, analyze data, share results, and distribute systems" "regardless of experience".

 

What I (And I think many others) miss is that there's a serious side to using LV which can only be harnessed by experienced programmers.  I feel that NI should focus more on this "experience scaleability" of LabVIEW which makes it easy to learn but very difficult to master due to the incredible breadth of features and possibilities LV offers.  I'm not a marketing guy, so pelase don't ask me how to do this, but I think that maybe highlighting the software engineering side of LV development would help.  How about pushing examples of the classic software architectures or demonstrating some more advanced features which don't work "regardless of experience".

 

LabVIEW grows with any user's knowledge of software engineering and I just feel that this should be focussed on a bit more.

 

I'm interested to hear people's opinions.....

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!
Idea Statuses
Top Kudoed Authors