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!
Have you ever wanted to place a probe on a loop iteration counter? I can't tell you how many VIs I have with a wire from the iteration counter to the loop boundary just so I can put a probe there (Maybe a pop up iter. count would suffice). Or probe an output terminal on a VI that is not wired. I know you can open the VI and put a probe on the wire but..
There are probably more cases.
Minor issue, but since we have a chance to ask..has been bugging me for about 20 years now.
Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to
save to disk
read from disk
This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!
A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.
I have noticed in some places in the LabVIEW IDE that the selected attribute is not properly highlighted. A perfect example is Cursor Attributes on a Waveform Graph:
The currently selected Point Style and Cursor Style Attributes are highlighted with a blue box, but the Line Style and Line Width are not highlighted with the current values. This is important to know, because it is difficult to tell the difference in line widths, and could even be impossible if the cursor is off the screen.
I can only find these two places right now that the current selection is not highlighted, but once I find more I'll post in the comments.
When designing larger user interfaces often times my event structure ends up with many cases sorted in no real order. Commonly there are multiple controls that trigger the same event case. It is cumbersome to try and find the particular event case where a control is handled.
What I would like to see is a Find -> Event in the shortcut menu for a control. We can currently search for the front panel control, local variables and property nodes if used. It seems logical that events should be included in that list as well.
You can open a type definition by right-clicking a diagram terminal, constan, or front panel control, but it is not possible to get to a type def file just from a wire. There are a lot of times where I'm working on a diagram that uses a type definition that is only exposed as a wire. Right now, the process of getting to the type def is to create a temporary constant from the wire, then right click the constant. It would be nice to make it easier to get to the type def. And of course, I would like to have the same functionality for LabVIEW classes.
When building applications that use many different toolkits and classes, my build times can skyrocket. It's frustrating that while i'm waiting for my application to be built LabVIEW is useless for development. This is especially aggravating when I find a bug that takes 20 seconds to fix, but then building the application takes another 20 min. To address this issue I propose that there be an option to launch the build process in a separate process from the IDE so that I can continue working with my code in the meantime. This could mirror the FPGA compilation process where it used to block development but now is separated out.
Why optional though? For smaller applications the build process is very quick so if you can live with it I wouldn't want to always introduce the extra overhead that I assume would be necessary to lauch the build as a separate process.
When selecting properties from the Y Scale, I would expect to get the properties window opened for that axis. But no, you get the properties for the x-axis. But I distinctly selected the properties from within the Y Scale. See image below.
My suggestion is to open the properties window to the axis where the selection was made from.
It would be nice to have bookmarks (possibly based within the project) so that you could quickly jump to certain areas of your code that has to be modified or reviewed frequently. Obviously, things like state machines are self documenting, but it would still be great if you could quick jump to certain areas. Being project based, you could also jump to any bookmark in a subvi.
I'd really like to be able to select the entire top-level cluster in an event structure, if event data is a cluster:
I know this have been brought up in numerous forums over the years, but I feel it's being ignored somewhat by NI? It usually gathers quite a few positive acknowledgements from other users, but I think it's about three years since it's been brought up in the idea exchange. It seems so easy to implement and would greatly simplify many event structures. So forgive me for duplicating something from countless other places, but I think it deserves a second (or ninth or whatever) glance
The issue of a modal window being left open during debugging, only to jump to the front when the top level vi is run, has been an issue in LabVIEW for as long as I can remember. I am certian that every developer at one time or another experiences this behavior. There are several work arounds to this issue such as "the old 3 fingered salute" (CTRL+ALT+DEL) and kill LabVIEW, programmatically setting the window modality, external VI task managers, etc... however all of them are workarounds to deal with the issue.
The crux of the problem is that any front panel specified as modal immediately becomes modal as soon as the VI is reserved for execution. This proposal would establish additional option to the VI properties dialog (Modal when Executing). Which would only initiate the modal property of the window when the VI was actually executing.
There have been several similar ideas related to dealing with window modality (see below) however I believe this implementation is different than anything I was able to turn up in a search.