Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
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!
The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.
Yes, you can make custom probes for this behavior. But it should be native.
When you align a control that has increment/decrement buttons to other objects on the front panel that do not have them, LabVIEW aligns the buttons with the edge of the other controls. The align objects command should ignore the increment decrement buttons and align the border of the control with the borders of the other controls.
Workaround: Hide Inc/Dec Buttons, align objects, Show Inc/Dec buttons. However not as convenient.
Installers should show the public version of dependencies instead of internal versions.
This is a specific example, but I presume this behavior is more widespread: An Add-On that has a dependency on LabVIEW NXG doesn’t list the (public) version of LabVIEW NXG upon which it depends.
The OpenG Library v220.127.116.11 depends on LabVIEW NXG v1.0. But the installer indicates the version of LabVIEW NXG to be installed is v 18.104.22.168152-0+f0. To someone not familiar with the internal version numbering for LabVIEW NXG, it’s not obvious that this refers to LabVIEW NXG 1.0. This may lead someone to install an undesired version of NXG.
(I had NXG 2.0 already installed, and I assumed, incorrectly, that the version of NXG that the OpenG dependency referred to would also be NXG 2.0.)
By changing some NIPM settings (e.g., enable the "Show full version numbers and infrastructure packages" option), one can logically (but not definitively) deduce the public version that the internal version is referring to:
Please make the next version of LabVIEW a major update of the features we have available to create user interfaces.
2011 was the "improved stability" version. 2014 should be the year it became simple and fun to create user interfaces that blow everyone's socks off. I'm not even talking about fancy stuff, just get the basics right! Fix the graph indicators, and provide better front panel scaling options - and that alone will make 2014 the best update ever(!).
I started writing a list of all the things I find bad with the graph/charts for example, and found out that it would be better to just do a search here on the idea exchange to see how many ideas mention graphs alone. 2390 ideas! (yes, I have not gone through them all to filter out the ones that do not actually request changes to the graphs, but most of them do, directly or indirectly...). My own little list started like this, in random order:
Graphs and charts
1. You cannot stack plots in any of the graph indicators, only in charts 2. Number of plots stacked cannot be varied at run-time 3. Annotation properties are only partially available programmatically 4. Auto-scaling cannot be restricted to one way-only, it's behaviour cannot be configured in any way 5. Legends, palettes and tools do not fit together to form an organized user interface, nor are they possible to detach from eachother to get more flexible designs/scaling for ecxample... 6. XY graphs become sluggish and almost unusable with large data sets, where alternatives written in other languages have no performance issues 7. Plot colors could automatically adjust to the chosen background color - suggesting unique colors for the added plots that provide the best possible visibility.
8. Graphs on e.g. Google and Yahoo have tonnes of cool features like animated zooming, thumbnail graphs, highlighting of the plot you hover the mouse over etc. which provide a very interactive feeling, you can achieve some of this in LV as well, but it could/should be possible with little or no programming
9. To get charts to accept data with variable sample rate (delta X) is possible, but cumbersome and an almost hidden feature...
Mixed signal 1. You cannot set the group names programmatically 2. The number of plot areas is not configurable at run-time 3. You cannot assign plots to a given group programmatically 4. You cannot show the visibility checkbox of each plot etc.
And then you have the additional 2000 ideas...;-)
As for front panel scaling there are not that many ideas (naturally), but the impact/value of them would change every LabVIEW programmer's life significantly. We can stop spending so much time finding ways around limitations in LV, and start focusing on the actual goal of our applications.
The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.
We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)
I would like to request a feature that allows us to easily and permanently remove any entry in the list. (...maybe it could even show for pinned entries?)
IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.
It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.
These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.
Once in a while I complain about font issues in general (here, here, or here), but one of the really weird things are the font sizes as used in LabVIEW.
The font dialog lists them as units of pt, but for some reason they are quite different in size from the same sizes in any other applications (browser, word, etc.). LabVIEW also shows other problems, for example tahoma 14, 15 all look exactly the same... why??
Here is a side-by-side comparison of a wordpad document and a LabVIEW panel. Each line is configured for the indicated font size.
As you can easily see, LabVIEW is the exception. Any other applications I tried agrees with the left panel.
Having a continuous integration system is an essential component of software development:
Continuous Integration Process
This system requires automating the building process.
The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.
But the community has supplied a few sollutions to achieve this: CLI Tool
On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.
This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.
My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.
Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:
All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.
I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):
Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:
Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!
NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.
I suggest that NI start shipping USB keys instead. USB has several advantages:
USBs are smaller
USBs are more usable on devices without DVD player
Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.
When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:
Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons. Which one is which? There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon. Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.
NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW
I don't like the way that long file paths are shown in path controls and indicators: If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit. This can be pretty confusing.
One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown. I've seen this in other UIs and it should be a natural thing for users to understand.
Here's an illustration:
I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.
I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.
There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:
I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):
1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.
2) The "View As Color Box" option is available only when the numeric is U32.
3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.
Several ideas would be fixed by this, for instance this and this.
There's a common convention in LabVIEW where if a control is not a required input, you place the default value in parentheses:
For the most part this make sense and is useful when calling VIs, but there is one place where it's really annoying:
We know there's no error by default. I suggest that NI simply remove this. This can be done today by going to <vi.lib>\errclust.llb and modifying the control, but that's annoying to do with every installation.
I would even go so far as to say that NI should write a VI which will go through vi.lib and remove the text from all the existing VIs. I doubt this would have any backward compatibility issues, because I think the only place where those would be relevant is if someone is calling a VI in vi.lib dynamically AND setting the error in value, and frankly, those people deserve to be punished.