The probe watch window is not practical. Principially the probe watch window is a nice feature in some cases. But nevertheless when you only just want to place a probe , e.g. a conditional boolean probe, with one click like you are used to do in the past, now you need several clicks to get the same "result": You have to select the probe in the probe watch window again, add an additional probe window explicitely and then hide the probe wath window (because in general it bothers the developer because it covers the blockdiagramms and frontpanels).
My suggestion is to give the option to disable the probe watch window and enable the probe placement like in the past by adding an config entry in the LabView options or a better by adding parameters/shortcuts to the probe watch window.
It seems that LV Compare doesn't work with Statecharts (.lvsc files)
It's important for maintaining code quality to be able to use Diff (and why not merge) functionality also for statecharts.
I realize that this is more complex than comparing simple VIs, but I'm sure the great programmers at NI will figure out a way to create and present such compare results.
currently the property node only accepts a single reference.
For setting a property or calling a method on an array of references,
it is currently required to surround the node with a for loop.
It would be much easier if the array of references could be directly conected to the node,
especially for situations like enabling, hiding, ... a list of controls
For FPGA programming, sometimes I want a smaller representation of the loop iteration terminal on the for loop mostly just to squeeze every last gate out of the chip. Other times I want the integer to be unsigned or larger to prevent saturation.
I think everyone's been there before.
Working on a project and for some reason from somewhere an Insane Object appears somewhere in the code. Not a nice thing to have happen.
At the moment, it's quite a nasty job trying to track these things down. Usually most users resort to trial and error in trying to find the culprit. I myself use the mass compile function to at least narrow down which files have the problems. Recently there was a post on the Forums highlighting the LabVIEW Object Viewer which seems like something which should be much more accessable.
I would like to propose making tools like these more accessable, more usable and maybe adding a tutorial as to how to deal with this. I also would like to see more sanity checks for the LV code so that we could maybe catch these erros earlier. How about an error whenever saving a VI so that we can 1) attempt another save in case the error comes from a write error or 2) investigate the problem immediately so that we can rest assured that we have caught the problem early enough to prevent tearing down the whole project.
A while back, Dany Allard suggested merge and diff tools for projects and libraries. I have a request that is similar, but more specific:
When opening a project, if for various reasons LabVIEW is unable to locate dependencies of a build specification, it would be truly helpful if the user was prompted to locate said dependencies. As it stands, by my observation LabVIEW silently omits missing build spec dependencies - this can be frustrating and dangerous.
Here's some context: I have lots of projects with 5+ build specifications. When I move directories, files, or even change LabVIEW versions, my build specifications stealthily fall apart, sometimes very subtly. Often I don't realize that my build spec is broken until I attempt to build, only to realize that it's a hollow placeholder in my project file. The most insidious case is when the application builds successfully, but is missing dynamic VIs, etc. This omission might go completely unnoticed without rigorous testing. LabVIEW should, in my opinion, give the user some indication that the build specification is missing dependencies or is "broken."
One hypothetical way to indicate this status might be to list the build spec in red font within Project Explorer, and have dependencies listed in dimmed font within respective build spec dialogs. There ought to be a "resolve conflicts" button in the build spec dialog; Perhaps this functionality could be integrated in the main conflict resolution dialog somehow.
Furthermore, there ought to be an option to import build specs from other projects. (Okay, maybe this should be a separate request) When importing, the aforementioned conflict resolution process should be leveraged to make the import proceed smoothly.
Has this already been requested? Thanks for listening.
1) I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes
2) A shortcut to make the selected "control label" in the front panel or block diagram to make it BOLD. (CTRL+SHIFT+B) or anything equivalent
To conserve the real estate, can we alter the controls/indicators to have labels "on" them. In that way, we can save the real-estate. The controls and indicators could have the auto-size feature if the labels need to be longer. This would make it cleaner.
I'd love it if the LabVIEW developers optimized the search speed for searching pallettes for VIs. When I hit the Search button on the Controls pallette, it can take 30 seconds or more before I can search as it says "Populating List...Please Wait." It would be great if LabVIEW could populate the list as a background task sometime after startup such that when we need this function it would be ready to go without waiting.
In Front panel when a button is created it will have default Label name so when Ctrl + Click and Drag the a new button identical to the button will get created and the label will be created with a number. This should also be applicable to Boolean text I never came accross a situation to have two buttons with the same boolean text.
I guess this would be useful.
I frequently have to compare the contents of two folders, each of which contain the same structure, but slight modifications of low level VIs. Does NI have plans to implement a comparison tool to compare the differences between two different folders and their contents? I found a compare vi executable, but to utilze it, I would need to modify a batch file and name all .vi files and their paths, which slows my progress.
I would like a better way to clear the list of recent files and recent projects in LabView. It is often disireable to clear the history when changing to a different project or a different user. Currently the user must close LV, edit the .ini file and restart LV. I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.
Currently, when the VI is being created the controls and indicators placed on the block diagram look messy/unordered on the Front Panel (FP). Example below:
Wouldn't be better if LV simply do the basic aligment for the users?
1. Inputs on the left hand side
2. Outputs on the right hand side
3. Error controls always on the bottom
4. Vertical order of the controls and indicators by order of apperance in block diagram
Example of the result:
I'd like an option to the 'value' property (especially for clusters) to enable/disable showing the parent.
In the example below, I'd like to toggle whether the parent is shown on the default label when I create the value property from filename (hide parent) to old datum: filename (show parent)...
It would be nice not only to be able to toggle this for specific instances, but also to be able to set the default as a VI property (and a project property).
Sometimes when searching, certain subVI's take forever to get through, and they're almost never what I'm interested in searching. A simple checkbox in the VI properties that said something like "Skip this VI when searching" would fix this neatly.
(slight aside, two of the slow ones have a bunch of .NET calls in them)
The only other way I know of to accomplish something similar is to password protect the slow VI's, but I work on a team and that would be a hassle for everyone.
This is related to the following suggestion, which is to allow multiple search windows to be open. If that were implemented, it would at least make the slow searching less painful, by letting me keep previous results. But I often end up wiping out the search results by doing something like 'find all instances', and then I'm back to the slow search.
I have tailored the 3D plot, but I can not tailor it enough. I want to be able to draw additional lines, rectangles, circles, semi-circles and text in the XY-plane, in addition to what's already in the 3D-plot. The current implementation of the 3D-plots with their X-controls and helpers do not allow me to add these extra's.
Once I figured the X-control concept, and followed a suggestion somewhere on the fora on how to disable normalization of quiver length somewhere deep down in the quiver class, I browsed through the hundreds of underlying VI's and it is clear that the capability is somewhere in the supporting LV-native engine, but it is not exposed to the end-user of the plots. So I am now struggling to make my own class and xcontrol to make it work.
My matlab colleagues have it easier in this respect.
Give the user the ability to save the LabVIEW source files as un-completed, version independent files capable of being imported to any version of LabVIEW. Of course, newer features won't be recognized, but the vast majority of the code should be useable.