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!
I'm developing some software for a colleague, to run on (one of) his machines. I do my best to follow Good LabVIEW Practices, including using Version Control (SVN) to maintain my code. Hence my Project "jumps" from computer to computer.
I recently noticed an old problem re-appear, namely occasional Front Panel and Block Diagram labels appearing in a different Font Size (18) than I've set as the default on my Office Desktop and home Laptop (15). This was really irritating (especially having to find those wayward labels and "fix" them), forcing me to re-examine the Where and How of setting Default Fonts in LabVIEW.
This still appears to be a Dark Art, one (perhaps) involving LabVIEW.ini (and some undocumented keys, not present in the "vanilla" configuration file). There appear to be several such INI files, with LabVIEW.ini attuned for development, and an INI file in the Data folder of a built Executable for that Executable. But still, the values are bereft of documentation (i.e. documentation is conspicuous by its absence) and not everything is explained (like why some values are in quotes, what they mean, and how one sets a specific Font, e.g. Arial).
One thing that I, in particular, would like to see would be the ability to set the Font Defaults on a Project basis. For myself, I "own" the Project, and would want it to have a consistent Font (size) on all my VIs (unless I specifically decide to Emphasize something), no matter on what machine I develop them and when. If I have to set the Font Default on a machine-wide basis, then every time I develop on my colleague's PC, I'd have to (a) note his settings, (b) change them to mine, and (c) remember to set them back when I finish. As such sessions are often an hour here, an hour there, this "machine-centric" setting becomes a nuisance fast.
I recently had the opportunity to discuss this with an NI Applications Engineer, who assisted me in finding (some of) the obscure references to Font Setting Tricks. I noted that a lot of what the Community knows seems to come from "Reverse-Engineering" NI's settings, and that some Documentation and Standardization (let's get away from designating Fonts as "1", "2", or "3", which have no intrinsic meaning, please) would be a good idea. Hence this LabVIEW Idea.
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.
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.
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.
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.
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.
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.
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.
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!
This is a bit of a pet peeve of mine while programming, a tunnel placed at the midway of a structures edge will be covered by the resize handle when you want to move/select the tunnel. It would be nice if the tunnel had precidence over the resize handle on the structure, and as such would be cover the resize handle so that you could more easily access the tunnel instead of the other way around like it is now. If you need to resize the structure, there are handles at the edge of the structure, and a Ctrl press while resizing will lock the regrowth to one direction, so the center handle access really isn't as needed.
The documentation states that the Tip Strip is limited to 255 characters, however the Documentation tab of a control Properties page does no checking against that limit. One will only find out if there are more than 255 characters during execution, when the tip strip is truncated!
Please enforce the character limit of the Tip Strip input box, at design time. Also, while at it, make that box taller.
I really like having two different default locations for my terminal labels. What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control. I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed.
You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved. And I am not interested in the Quick Drop shortcut here. I do not want a quick way to clean up the mess I do not want the mess made in the first place.
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.