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

NI LabVIEW allows VIs with invalid characters such as "?" in the filename inside an LLB file as shown below:

LLB.png

 

However when it comes to building a Source Distribution / TestStand Deployment that uses this file it returns an error as shown below:

Build Error.png

 

This inconsistency within LabVIEW is quite frustrating where one part allows invalid characters in the filename and another part will return an error. Since the invalid characters are allowed in VI filenames within LLB files I would suggest that the LabVIEW build tools also handle them graciously.

 

During the build process it could quite easily rename the file "pi40iv Can Connect Channel?.vi" to "pi40iv Can Connect Channel_.vi"  and link the VIs that use it to the newly renamed file. The build tools already contain the ability to rename files by adding prefixes so something like this would not be that difficult.

 

While people may argue to just rename the filename within the LLB and be done with it, the fact that the LLB is a perfectly valid file in the Development Environment but causes problems when trying to do a build is a problem that should be rectified.

 

The LLB in question is one that is not developed by us but is part of a Pickering Driver Installation obtained from the following location:

http://downloads.pickeringtest.info/downloads/drivers/IVI/

Therefore every time we install a new version of the driver we would need to rename the VI filename within the LLB file.

Add "Find All Instances" for polymorphic VIs. Right-clicking a normal VI's icon in the upper-right displays a pop-up menu with quick access to a "Find All Instances" item which helps greatly when navigating code to find all callers, then their callers, etc. However, when a caller happens to be polymorphic "Find All Instances" is not available and the work-flow is broken. Ctrl+F or Edit, Find can be used but the Find dialog must be manually configured: "Search for" Objects may have to be selected if Text was last used; "Select Object" must be set from a looong list of VIs. By that time, concentration is lost.

  • UI & Usability

Hello all

Currently the Report Generation Tookit allows you to print excel/word documents.

However, when printing excel files it always prints the worksheet.

In some cases, it is a big advantage in printing the whole workbook instead just the current worksheet.

When printing the whole workbook at once, the page index at every single worksheet automatically count’s up. (page x or page x of y changes automatically and takes all worksheet’s into account)

 

This can be done in changing the reference from worksheet to workbook in the internal report generation function.

I have done that by myself, in my LabVIEW environment. It’s an easy thing. However, it has to be done for any single Computer using LabVIEW and in any single LabVIEW version installed on that computer.

Unfortunately, it is not possible to just change the report generation “print” vi and save it in my library/ project, since it’s owning the report generation classes. If the vi is saved outside the original class library you get a broken arrow…

 

So I really hope that you all also like this idea!

 

  • UI & Usability

When setting up In Place Element structures, the current work flow is:

 

  • Drop the structure
  • Right click, add the node you want
  • Wire the reference / array / variant in

It would also be nice to wire the references I want to use to the border of my IPE structure, right click on the tunnel (c.f. for and while loop auto-indexing context, or shift register/tunnel) and select from a sensible list of incoming element types relevant to my incoming wire.

This would be fantastic to see alongside similar ideas such as this or this.

dvr-rcm.png

  • UI & Usability

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:

2017-09-28_11-42-52.png

Should be quite easy to change the property page like e.g:

LabVIEW_2017-09-28_11-02-36.png

(6 colors for system booleans, 4 for all others, as known)

 

 

  • UI & Usability

These context menu items should be swapped to be intuitively ordered so Before is before After and After is after Before. With a Case Structure, Diagram Disable Structure, Conditional Disable Structure, and Flat Sequence Structure, the right-click pop-up menu items to Add Case, Subdiagram, or Frame After are first and before the Add ... Before items. These being opposite intuition always make me pause and think to pick the right one. Help us be more productive, please.

  • UI & Usability

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

  • UI & Usability

I've been programming in LabVIEW for a decade.  Yet, there is still an issue with type def'ing a cluster.  If one of the goals of LabVIEW programming is documentation, why does NI still make it the process difficult?   

 

After creating then 'type def' a cluster, I then have to more spend time unhiding and repositioning labels. This gets extremely inefficient with large cluster.

 

Why not add an option to hide or leave labels untouched when 'type def'ing a cluster?

 

2017-10-25 10_40_31- LabVIEW issue.png

 

  • UI & Usability

As discussed here, please incorporate the System Controls 2.0 UI elements into core LabVIEW. This would eliminate the need to visit VIPM to obtain the full functionality of the System UI control palette. System Controls 2.0 is not an additional UI style, rather it is the partial completion of the original System controls palette.

 

Including these controls in the default installation would allow the merging of these two palette entries for those that use the System controls for UI development.

 

system.png

 

 

  • UI & Usability

I would like to have the possibility to "negate" some comparison functions such as "Empty String/Path?". This can avoid to add the "Not" operator.

The picture below is a possible implementation. The dot on the input (on the output ok also) is showing the negation.

Labview Idea.png

This might be good to be implemented for the following functions:

Labview Idea 2.png

  • UI & Usability

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.

 

In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".

 

If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.

 

If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.

 

-------------------------- Example ----------------------------------------------------------------------

 size to widest.pngsize to widest2.png

 

 

 

 

  • UI & Usability

Once in a while I encounter a case or event list that forces me to grow the structure

- in order to keep the list readable:

Selector.png

It would be nice if the item-list would automatically "wrap" instead.  

Selector4.png

  • UI & Usability

Here's a dumb mistake I think many of us can relate to:

bundle_by_name.gif

It would be really nice if the VI were just broken in this situation. But I can understand why it's not necessarily simple to mark node *outputs* as required.

 

 

But maybe there could be a way for the editor to *hint* that there is a problem here. Maybe the bundle nodes could change color when the output terminal is wired, so you could get a little more obvious feedback if you screwed up like this.  The same could go for any other primitives that have a "for type" input (e.g. unflatten from string, variant to data, to more specific class, etc).

 

Granted, VI Analyzer could report bugs like this, but having a little more immediate feedback would probably be a big win.

 

(Let me know if this should be cross-posted to the NXG idea exchange, too).

  • UI & Usability

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However,  at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

 

  • UI & Usability

The In Place Array Index/Replace Elements function not only can save memory by avoiding copying arrays, it can also create "neater" and more transparent Block Diagrams.  For example, here are two ways to triple the third element in an Array of 3 elements:

 

Array Index-Replace 1D.png

I needed to do the same thing, but for a 2D array (three channels of A/D data, I wanted to triple the third channel).  The Help for the In Place Array Index/Replace Subset function suggests this is possible, using language like "element or element(s) of an array", noting the similarity between this In Place Structure and the two Array Functions that form the Input and Output nodes, and in earlier versions of LabVIEW (specifically LabVIEW 2012), explicit reference to rows, columns, and pages as replacement items.  Here's what happens:

Array Index-Replace 2D.png

The Index Array left node forces you to specify both row and column, meaning you cannot operate on a single row (or single column), "breaking" the functionality with the separate Index Array/Replace Subset functions.  This also, I believe, will force an Array Copy operation, something I'm (also) trying to avoid.

 

At its most benign, there is a Documentation "Bug" that should warn users that this In Place function is only designed for single array elements (which, in my opinion, severely limits its usefulness).  I would like to suggest that this function be "fixed" to (a) for multi-dimension Arrays, allow, as with Index Array and Replace Subset, flexible choice of one or more Indices to be specified, with the unspecified Indices implying "All of the Elements", i.e. an entire Row, Column, Page, etc, and (b) maintain the "In Place" functionality by having this function generate the necessary code (behind the scenes) to access the specified elements and do whatever operation is required inside the Structure.

 

I appreciate that requirement (b) might be difficult.  For instance, operating on a row in a 2D array should be easy, as the (row) elements should be continguous, making getting and putting them simple.  However, if a column is specified, getting successive elements and putting them back becomes more complex.  To the User, it all "looks simple" -- you get a 1D wire out, operate on it (say, multiply it by 3), and stick it back "in place", but the LabVIEW compiler has to "get" elements from non-continuous locations and put them back where it got them, but that's what Compilers are for!

 

Bob Schor

Bookmarks should NOT be created unless the first character after # is an alphabetic character. http://zone.ni.com/reference/en-XX/help/371361N-01/lvhowto/manage_tasks_lv/ says "hashtag followed by text is called a bookmark." Although it says # followed by text, it is not only creating them from alphabet characters but also numbers and symbols, e.g. "ID #132", "(###-###-####)". The number of unintended entries in the Bookmark Manager can render the feature almost worthless, especially when upgrading from 2012 or earlier. There are so many non-bookmark values that the presence of any real bookmark (e.g. code to fix) is lost like a needle in a haystack. I know others (e.g. QFang) liberally use "#" in controls, indicators, descriptions, comments, etc. as shorthand for "number" or "number of". There should be few objections since digits and symbols can be in bookmarks after the first character following #.

  • UI & Usability

This idea is to improve the QuickDrop search window, to return functions that might be betters suited, based on the datatype of the selected function or wire.  Lets say I have a 1D array of numerics selected and I want to reverse it.  I will select the wire, then invoke QD and type "reverse".  But the first item in the list is actually "Reverse String".  With a context aware QD hopefully the search window will see I have an array of numerics, and prioritize the Reverse 1D Array function, and still include the reverse string but maybe push it farther down the list.  

 

This idea can be applied to the basic data types pretty easily (numerics, boolean, array, string, cluster).  But we could also use this on class wires that are selected.  A class library can have an associated mnu file, which is why some functions you can right click and the corresponding subpalette menu comes up.  So this idea could also prioritize functions that are found in the mnu associated with the class.

  • UI & Usability

The "Read Key (Double).vi" is not giving out proper values when a SI notation number is present in the ini file. For e.g. if the number is 1m it returns as 1 while the actual value should be 0.001. It will be helpful if the format specifier is provided as another control.

  • UI & Usability

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

 

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

 

Here is a simplified example to illustrate the problem (see picture).

 

 

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

 

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course Smiley Happy). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

 

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

 

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

 

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

 

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

 

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

  • UI & Usability

After reading Restore High Contrast Icons I procrastinated as long as possible before installing LV2016.  When I finally did, I was disappointed by the additional space required for the palettes; all of them!  I have been using LabVIEW since 5.0 and switched to an Icon view of the palettes shortly after getting comfortable with the graphics.  Now, I have to move my mouse further to get to each sub-menu and VI selection.  It's a waste of developer's time and apparently done for absolutely no good reason except to make a change; very similar to the washed out icons.

This extra space needs to be removed or at least an option provided to set the spacing back to the condensed spacing always available.

These images to show the relative size of the palettes LV2016 vs. 2015.

Controls Palette

ControlsPalette

BoolenPalette

Functions Palette

FunctionsPalette.png

ArrayPalette

 

Yes, this might seem trivial, until you think about traversing several palettes to get to your needed VI.

 

FTPPalette

*Random example, if one were doing FTP development they'd pin the menu.

** The original size of the above graphic is 1030 pixels wide; less than 800 for 2015.

 

Quit messing with what works and has become the standard with regards to options.  At least when that ridiculous "default" setting for icons instead of terminals was introduced we could undo the setting in Options

It seems that NI has hired some non-G experts to mess up the interface simply so they can enumerate all the "great" improvements they've made.  Or, was all the extra space to make sure newbies couldn't miss the folder tab, since connecting the "right arrow" on an icon to it being a sub-folder would be too difficult for children?

 

  • UI & Usability