LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
This is only a wish that NI could provide a Utility that converts a VI or Dir to Up or Down.

I had a project that was done in LabVIEW 5 (done many years ago by someone else); I couldn’t open in LabVIEW 8.6. I needed to do stage upgrade LabVIEW 7 and follow up with LabVIEW 8.6 and so on.

I understand there are cases that you can not simply down convert, because newer function may not be available in older version. In this case it OK, give user an option for force the convert and worse case the down convert VI is broken. Let the programmer fix it!

The utility should have a Status Report for convention.

Please..!

The title says it all - I'd like to have the option to inherit my configuration settings from the previous LabVIEW installation (or from a specified path).  Currently I have to do this manually by copying the ini file from the previous version, but I'm never sure whether there will be compatibility issues with the new version of LabVIEW or if there are obsolete settings.  The installer should check for compatibility/obsolescence issues as it creates the new ini file.

 

Alternatively / additionally, I'd like to be able to specify where LabVIEW loads the LabVIEW.ini file from (which could be located on a network or USB disk).

I just would like to have a shortcut menu option that allow to add or remove output element for Index Array Element basic function.  Build Array function already support this options for their inputs, it'll be helpfull that Index Array has the same shortcuts in order to insert or remove an output between both of them.

 

IndexArrayAdd-Remove Function 

In text base programming, it is possible to modify the value of a variable in debug mode.  It would be great if LabVIEW can do the same thing.  This will give user more flexibility for debugging. 
I use a number of file and libraries common to all my applications.
To lighten the display would be nice to exclude certain folder from VI Hierarchy

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:

 

ShowAttributeSelection.png

 

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.

I would sometimes like to be able to switch the T/F cases on the select VI, the same way that you can right click a case structure and choose "make this case true/false". This would allow for less moving of things around or adding "not" before wiring the boolean up. The example here is simple, and obviously it would be easy enough to just switch things. But when you have a lot more code, it's not always quite so easy to do and can be time consuming.

 

Message Edited by for(imstuck) on 02-12-2010 04:48 PM
I would like to see a feature where the size of the tree images can be set by the developer.

I have 2 suggestions for the highlight feature.

 
  1. A slide bar or some other way to set the speed that the highlight runs.
 
  1.  A way to only highlight a section of code but run the rest full speed.
 

Maybe it could it be done by selecting an area, as done with the diagram disable?

Or with break points. Highlight between points?

 

Most of the time when highlighting, you don’t need the entire VI to highlight just one small section or frame. So, you put in a break point before and after the section you want. When the code pauses, you turn highlight on. When it pauses again, you turn it off. On large loop iterations, this is very time consuming.

 

An example would be for nested loops. If there are 3 nested loops and you would like to highlight one small area of code in the second loop. You have to: continually wait for the inner loop in highlight, or pause-highlight-unpause every iteration.

Would be nice having a way to send the (0,0) coordinates back the original position (top left of the form) moving all controls, keeping the relative position among then.
It would be nice if there was a way to include the conditional disable option in the build settings for executables. 

Populating values to the "enum" control is not possible by using the "strings" property node and hence to populate a large data to a "enum" one has to create a "Ring" control use the "strings" property and replace that "ring" with the enum (or if you have enough time enter them manually) .

 

So why not use the "Strings" property of "Enum" to write values to it directly..See the image attached

 

 

Usally  we can add a event case by right clicking the event structure and adding it.

Its seems to be little time consuming if we need more cases. It would be better if we can add

all cases on single go.

 

So editor need to be modified such that we can select objects and events for each case.

 

I would like to see the "radix" visible in the probes for "Numeric probes" and "hexadecimal/coded display" for "string" probes

Currently, LabVIEW is great at auto-coercing data as needed with all those nifty red dots.  However, it would be nice to have a primitive to manually force coercion.  This can currently sort of be done by using a Variant to Data primitive.  However, this has the problem of not doing the error checking until run-time, when it really could be done at compile time.   Here are a couple of examples where this would be useful.

 

coercion.PNG

 

In both cases, the Variant to Data has the desired effect.  However, since LabVIEW can check at compile time whether the coercion is valid, there is no need for error wires, which the Variant to Data primitive has.

 

In the 2nd example, there are several instances in LabVIEW where it uses the name of the data on the block diagram.  In this case, you select which event you want to handle based on the name.  If I did not add the Variant to Data primitive, the event would be named "Event 2", which would be undesired (and incorrect) if TRUE was wired to the Select primitive.

Like LabWindows, having all the Vi inside the main frame. Can desing easily all the FP, get quik access to the BD. When executing the VI, having the panel Load front as it will be in executable. Can acess to the VI FP or BD by clicking into the left tree or by the bottom tab.
Message Edited by CFiset on 12-21-2009 12:10 PM

I like to keep my code tidy and aligned.

However, nearly every time when I need the select function, I 'd like to have the 'true case' at the bottom side.  Now I add an invert function to keep the code tidy.

My idea:

Add an extra select function with the True case at the bottom side or add an option to the current select function 'invert selector'.

 

AdjustedSelect.png

I would like to pop-up and put a probe on the iteration terminal of loops to look at the loop count without having to wire the terminal to an indicator first.

Currently we can set Conditional Disable Symbols (CDS) for a whole project or for a target.

I wish we were able to set them inside a build spec, too.

 

This would mean, I could have a large application in one project and build different flavours of it's executable simply by using the appropriate build specs.

Use cases might include simple things like debug / release builds (similar to this idea), but also more complex differences like a software that uses real hardware and a special version that works without hardware, which can be used in the office.

 

Currently I need to either set the CDSs manually each time I build an executable or maintain several copies of the same project file. Both methods are tedious and error-prone.

 

I miss the possibility to 

 

- add COM compatibility to .NET Interop Assembly builds

- add COM  compatibility to Shared DLL builds

 

 

I missed LV help information about the need to add a key file (*.snk) to the project first, before you can select it for signing the assembly. Unless you do that the file filter (*.snk) seems to fail when browsing.