when I want to know the execution duration of a special part in a VI, I have to stop it, place 2 tick counts (OpenG with error handling), place a substract, and then creating an indicator.
What I would have ? A special probe which could do the same thing quickly !
Have a nice day !
Users never seem to know about the shipping examples unless someone from support directs them to one. Maybe I'm assuming that because I work in support, but then again I didn't find this treasure chest until someone had shown me. I propose that LabVIEW include an "Example Button" which is in clear view at the top of the block diagram and front panel. When this button has been selected, you can hover over any VI and a list of shipping examples could be displayed. As well, I think it would be a nice feature for there to also be an option to display videos of screenshots where the set up process is shown for each of the examples. I think that the videos are just as important as the example button itself. They will help customers see a cursor navigate to the location of each VI necessary for the particular example that has been selected. This will help customers become more familiar with the palettes and where to find basic VIs for design. As well, when you hover over the Example button, an explanation could be given for its use. This would defintely help customers that need step by step guidance because programming is not second nature to them. Currently even experienced programmers can get lost when first exposed to LabVIEW. This feature would be a type of adaptive tutorial that helps expose different features that a customer is searching for immediately.
It would be great to have possibility to change/edit the code when a VI is running in "Suspend when called mode".
I mean when the VI is "paused" and waiting for you to press the "run" button, right there, possibility to edit the code for that VI and run it ones, change a little bit and run it again and again...
I know that this means a lot for the NI developer team to solve..
But what a functionality when you are into fault finding and testing out of new developed code! ! !
Currently if you try deleting a registry key with sub-keys, LabVIEW will throw error -604 until all the sub-keys are deleted first. There should be an option on this VI to automatically delete the sub-keys first.
Just like LabVIEW 2009 introduced Custom User Hooks for Data Member Access and Override VI LVOOP templates....
I would like Custom User Hooks for Dynamic Dispatch and Static Dispatch LVOOP templates as well.
As per LabVIEW Help (pointed out by Jim_S - cheers) you cannot add an X-Control or X-Control Reference as a Class Data Member.
Well I found out (the hard way) that technically you can in dev time but at run time your build will be broken.
E.g. I would like the ability to add an X-Control Reference as a Data Member of a Class so that I can encapsulate display state changes whilst enjoying the benefits of Classes etc...
I have LabVIEW Classes of the same name in two separate LabVIEW Project Libraries (e.g. for namespacing reasons) in the same LabVIEW Project.
When I go to configure the Inheritance of the a Class, the All Class In Project list just shows the Class names.
These names can be the same and it is not immediately obvious which Class is the correct one.
The only way to pick the correct Class is by looking at the Selected Class Path on the right.
My idea is that the All Class In Project list will display the qualified names.
Either as one long name or nested, mimicking the LabVIEW Project hierarchy.
(I think I currently prefer nested).
The most common way to represent a polar graph is to place the values of the magnitude scale on the lines of the rotary axes instead of on lines emerging from the graph. For example to create a polar antenna radiation pattern.
Currently only shows the values of 0 º, 90 º, 180 º, 270 º. Should be able to set the angle to show, for example every 5 º.There is no possibility to scale the chart, and the value of the axis (magnitude vs. angle). Also growing charts on-line (by adding new points dynamically) is not possible or is extremely slow because it is a control chart based on images pixel by pixel.
In summary ... a Polar Plot.vi with the same properties as XY Graph or Waveform Chart or Graph.
I am not sure whether this is a bug or not but when you add a folder containing a X-Control Library to User.lib the auto-generated Controls Palette does not show the X-Control!
It only contains the Data control, State control and any other custom controls (e.g. in the example below StateDisplay is a typedef I created).
There is no way to drag and drop the X-Control in from the Palette - it has to be done from disk!
My idea is that the User.lib auto-generated Controls Palette should show any .ctl, .ctt or .xctl file.
The Windows 7 file permissions in the Program Files directory are causing a lot of headaches, especially with *.ini files of existing applications. It would be nice if LabVIEW had an option where install file paths of these files could be set based on the system they are going on. For instance, if the installer is being run on Windows XP, the installer will know to put the ini files in <Program Files>\<App Name>\Config but on Windows 7 install the files to <User>\Local Settings\... or whatever we choose.
Right now it seems our only option is to build 2 installers and have a batch file decide which to run. Unless, of course, someone can tell me otherwise.
If a control/indicator has a long label, the local variable takes a lot of space on the block diagram.
It would be nice if local variables can be resized, and
1) when the cursor is moved over the local variable, the full label is displayed just like a tip strip on a control/indicator; or
2) the label of the local variable should be defaulted to the same as the corresponding control/indicator, and can be turned to visible or invisible.
It would also be nice if an enum constant can be resized.
Since Microsoft Windows 7 will be supporting a host of new Touch Screen capabilities and urging Monitor Manufacturers to implement the technology. It would be nice if Front Panels could be made into a 3 dimensional Object like a cube. An example is the following the 3D picture controls in FP Main.vi. (LV 2009 only)
Displaying Front Panels and Block Diagrams. Blank Cubes could be created from the project explorer, a "flat" VI, or the LV Splash Screen. Blank Cubes would be gray with no Front Panel Icons. To populate the front panel or block diagram cubes, drag and drop VI's from the project explorer to a plane on the cube or drag the icon from a flat VI.
The user could have the ability to open numerous vi screens on their 3D object (up to 6 per cube). This would make scrolling from screen to screen as easy as moving your hand over the screen and navigating to the correct VI. If you select Control + E, you will be shown a 3D Cube of the Block diagram. Each Block diagram will correspond to a front panel and be mapped to the edge of the Cube. You could also have the option to create multiple Cubes so that you can have more than 6 VI's open at one time and drag/drop more VI's to this blank cube. If the block diagram cube for a front panel cube is already open and you press control + E for a particular front panel, the block diagram cube will reorient itself to show the correct diagram. (and Vice Versa)
I find it takes a lot of clicking to examine LabVIEW code to understand what the code actually does. One such place that code is hidden is within a case structure.
Particularly for simple case structures, with only true/false conditions, it would be great to show both cases of the case structure on the diagram at the same time. This would help avoid users clicking through cases to review code, and would certainly help make printed-on-paper LV diagrams more useful.
Here's an example of such a case structure:
as opposed to the current behavior, where either the True or the False case is shown at a given time.
Note: I'm presuming LabVIEW's editor wouldn't allow the user to edit in the 'gray area' in the mockup above, and there are surely some details to work out in terms of how wiring those tunnels would work. But this would be cool to make a reality!
Whenever I turn on Hightight Execution, there may be a lot of display area that is not in my active window. How about limiting the Highlight Execution to only the part of the Block Diagram that is visible? This will greatly speed up the process if there is a lot of the block diagram that I'm not interested in.
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.
When you have several arrays of the same size and you need to sort them one can use the "Index & Bundle Cluster Array", use the "Sort 1D Array", the put down a for loop and then unbundle to get the arrays back to arrays. It would be nice to have the reverse capability of "Index & Bundle Cluster Array" to make the array of clusters back to a group of arrays. In my testing the "Index & Bundle Cluster Array" was 5 times faster than a For loop and Bundle. I would assume that the reverse could also be much faster.
Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.
In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:
The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its
elements, as shown below.
However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.
This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.
This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.
For any FP terminal, if I have to create a control for its reference, I have to create a reference first and then the control for that reference. It's a 2-step process. If the reference is not going to be used anyway, you will have to delete that out as an extra step. Why not just have an option to create the control of the reference as shown below? This option would be really nice to have if we need to create reference controls for many terminals.
Also why label this control reference as "Numeric 2" while my original control was labeled "Numeric"? I am anyway going to delete that "2" and have a one-to-one correspondence of the reference control to the control itself. Are there any good reasons to justify the current behavior?