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 Kudoed 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
0 Kudos

I think there should be a way to reinitialize a stacked shift register to the originally initialized value so you can clear out the contents of every iteration all at once.  For example, the code below, implemented with 4 individual shift registers:

 

 multiple shift registers.PNG

 

Could be implemented with 1 stacked shift register with a reinitialize terminal:

 

stacked shift register with reinitialize.PNG 

0 Kudos

I would like the maximize button removed from the FP & especially the BD.  I typically work with many VIs open at once and I find it very annoying to open a subVI that consumes my entire desktop with a lot of white space. This is true of the FP and the BD.

 

Lets be real - your code is not that important.  The one except might be the main GUI.

0 Kudos

At least numeric controls and string controls loose focus after pressing enter. This is especially unpractically when navigating by key. The focus should be held on all controls as it is on boolean controls.

0 Kudos

Classes in LabVIEW are a great step over (and finally, with LV 2009 them start to work...) but there are still two 'holes'

 

Abstract methods. 

It would be great to have the possibility to define abstract methods and interfaces. Now I'm forcing an error into the error out indicator to notify the usage of a method not yet defined but it would be better to make the compiler to recognize the usage of abstract methods during the design time. One way to define abstract methods could be the introduction of a new entry in the 'class menu' and allowing to define them just in term of front panel (block diagram not available).

 

Class duplication.

An object is duplicated on each node, so is not easy to work into parralel loops on the same instance. To use the same instance I have used references, but it is not so easy to use (not as the 'normal' wires) and it hasn't the same performance (working with reference is heavier than working with instances). It would be great to introduce a mechanism that implements the convertion from instance to object, something likes a standard 'getReference' and 'getInstance'.

0 Kudos

it would be nice if we could copy teh changes from one vi to another while comparing two VI's

0 Kudos

Find and Replace should be expanded to sections of code.

0 Kudos

Hi,

 

Append True/False String is a function in LV, and it allows you to append one of the two input strings to the initial string based on a boolean input.  I use it to append pass/fail to the initial string. 

 

I think this function should also allow us to select a couple of standard true/false string without needing a true/false string input.  I should be able to right click on the node and select pass/fail, true/false, yes/no, go/no go, etc.  By doing this, we can make our code even cleaner.  When you select these standard true/false string, the appearance of the icon should also change in order to reflect what standard true/false input is selected.

 

Yik

0 Kudos

The Block Diagram should look more like a schematic capture tool.  It should have the ability to zoom in and out and pan.  Users should be able to draw their own Vis like ICs in a schematic capture program.  Parts and wires should be drawn on a grid.

0 Kudos

Hi all,

 

Sometimes, a cluster constant is used in LV.  Due to the size of the constant, a lot of time, it is sized down, so that only part of the constant is shown.  What if you want to see all the values in the cluster?  You have to size it up. 

 

At the moment, if we do ctrl+h and hoover over the constant, we will get some information about the constant, but not the values are in the constants.  It will be nice if the values are shown in the help window as well. 

 

Yik

0 Kudos

My apologies if this has already been suggested ...  I've written many VIs with a While loop that has True wired to the Stop terminal, making it a "Do Once" loop.  This is such a common construct (i.e. a VIG) that it might merit its own "structure", something that "looks like" a While loop but has no Stop terminal, no "i" indicator, and is guaranteed to "Run Once".  I think having a unique "look" for this common special use of the While loop would be a useful addition.  Among other things, it would clearly distinguish "purpose" as different than a While construct.

 

Bob Schor

0 Kudos

We need the ability to manage multiple volume licenses from a single VLM instance.  We have several groups from different cost centers that use LV; however, currently all the license administration falls on me.  The only solutions available at this time are:

  1. Merge all the licensing needs from each group into a single license.  This is a nightmare for me.  For one, our internal accounting system isn't set up to easily transfer funds between cost centers, so getting the money to pay for the license has been difficult and usually leads to payment delays.  Second, it's very difficult to respond to changing license requirements of an individual group when everything is lumped into a single license file.  If a single group wants to discontinue their subscription, rather than just letting the subscription expire (which would cancel the subscription for all groups) they have to pay a fee to "break out" their licenses from the volume license.  If a group wants to add products to their license, all requests get funnelled through me.  This might be good for NI, but it's a royal PITA for me.  (License administration is something I do in my "spare" time.)  Third, it's inconvenient having to track how many licenses of each type each group has purchased and cross check that against how many licenses they are using.
  2. Maintain separate computers for each VLA.  From an ease-of-use perspective this is almost as bad as option 1.  From a practical perspective this is worse than option 1.  It's silly to have several different computers sitting around doing nothing other than running a license server.  Furthermore, it's harder to loan an available license from one group to another group (which does sometimes happen) as the user has to redirect to a new license server.

Neither of these solutions work very well.  I don't mind the license administration part of the job.  Creating installers, changing permissions, and stuff like that doesn't really take that much time.  What is killing me is the account administration part of the job.  The single license model forces me to be an account administrator for several independent groups, and the corporate culture and infrastructure here don't support that model very well at all.  What I would like to be able to do is have each group be responsible for purchasing and maintaining their own volume license agreements.  When they get the license file they can send it to me and I'll install it in the VLM.

 

I envision each VLA having it's own root node in the tree diagram.  Instead of a single "Volume Licenses" node, there would be one for "Group A Licenses," another for "Group B Licenses," etc.  (I have to be able to rename or annotate the root node for each VLA.)  The Users and Computers nodes still contain the users and computers from all the groups, but maybe those nodes have virtual directories I can use to organize them.

0 Kudos

Currently, mass-compiling runs into problems with subversion files in "_svn" directories (files called X.vi.svn-base).  There should be a setting to exclude these directories.

0 Kudos

Ok, here's my suggestion: 

 

One minor annoyance with building pop-up subVIs is gracefully terminating the UI execution loop if the user closes the panel using the standard MS Windows "X" close button (upper right-hand corner of all standard Windows panels.)

 

Of course there are at least a couple of work-arounds -- disabling the Windows functionality completely, or polling to see if the panel is still open using a property node (and programmatically exiting the loop if it isn't). But I was thinking it would be nice if there was an option in the pop-up menu that forces a loop to terminate if the front panel window changes state from 'open' to 'closed'.

 

Alternatively, there could be a check-box option in the "Window Appearance" catagory of the "VI Properties" dialog that is something like this: "Auto-terminate loops when front panel closes". 

 

It's nice to offer users the familar functionality of the standard OS close buttons, but it would also be nice if there was a simple way to do this, without the programming overhead. (I've enclosed this functionality inside a subVI and it's relatively easy to drop this in and wire it up. Presumably, it wouldn't be too much work to add this capability right into the loop structure itself.)

 

I realize that this leads to questions about what to do with parameters that are usually passed when the loop is terminated in the 'correct' way -- the whole question of "OK" versus "Cancel". Perhaps Windows itself has a an answer to this question, and that could be adapted into the LabVIEW environment.

 

Anyway, it would sure be nice if there was a way to enable the standard OS close boxes without incurring the minor annoyance of programmatically terminating an active (while) loop or UI state machine after-the-fact.

 

Anyone agree?

 

 

 

0 Kudos

I use a number of file and libraries common to all my applications.
To lighten the display would be nice to exclude certain folder from VI Hierarchy

0 Kudos

It should be nice to add new VIs in the error handling palette.

 

These VIs could give, without having to analyse the satus or the error code, if there is no error, an error, a warning ....

 

So instead of testing the Status it could be ...

 

ErrorClusterOk.PNG

 

 

I know that the error cluster can be directly wired to a conditional terminal ...

but everytime you are in front of such a  diagram, you have to think of what will happen ? If i get an error the loop will stop or not ???

But using a kind of VI i describe previously ... there is no ambiguity ... it's clear !

 

 

 

 

0 Kudos

Currently when you open a Front Panel or Block Diagram it will open on whichever monitor you previously were working with it.    I suggest that when you move a VIs front panel to a specific monitor and then open the block diagram, it should open the BD on whichever monitor the FP is on.  This will help save user from having to continuously move many different windows from monitor to monitor.  This can also be extended to opening subVIs.  The subVIs front panel should open on the same monitor that the caller's block diagram is opened on.

0 Kudos

When working on a queued statemachine today, I realized its difficult to keep the wires straight. Usually you want one error wire going through your queue functions and into your subVIs but lining them up to keep the error wire straight often causes wires connected to the top connection terminal to get in each others way. If the queue functions icons were taller, this problem would be eliminated. See attached pictures

 

 

Message Edited by for(imstuck) on 02-05-2010 02:37 PM

0 Kudos

In addition to vision assistant script files (.scr) directly opening in vision assistant as suggested here, The icon can also be changed from this

 

 

script.JPG

to

 

 

niscript.JPG

 

Not neccasarily with the extention .scr as it will clash with windows screen saver. It can be .nscr or .niscr

0 Kudos

I want to swap sides for the scale on my Front Panel Tanks and DSC vessels like Pressurized Tank. 

 

This is very easy to do with a Waveform Chart or Graph but impossible with Tanks and Vessels unless you wire up some property node scheme to change the position of the scale, but then the indicator numbers are now between the vessel and the tick markers, making it a look a bit unnatural.

 

This would be very handy, especially for DSC processes where I'm trying to mimic process flow on the Front Panel and pipes could enter tanks from different sides.