NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
Marc Blumentritt

Project Based Environment

Status: New
by Member Marc Blumentritt on ‎10-19-2009 05:07 AM

Hi,

 

there is an idea about making labview.ini and other user configs to the corresponding user folder .

 

I propose to go a step further and make the LabVIEW environment project based, which means that you can define a labview.ini file, VI templates (including standard VI, if you create a new VI), palettes, QuickDrop stuff, etc. inside a project.

 

E.g. templates are saved in a custom location and linked inside the project. If you do this and start the "New..." dialog, than all your templates inside the project are listed first (below project).

 

If you do not use this feature in your project, the default files are used (default meaning the way LabVIEW works now).

 

Regards,

Marc

Ljubo

Mixed Signal Graph and Cursor Events

Status: New
by Member Ljubo on ‎10-19-2009 05:01 AM

It seems that Mixed Signal Graph does not know Cursor Events (Grab, Grab?, Move and Release). Is there any particular reason for this? If not please incorporate this idea in the next version of LabView.

DavyP

Missing Software Pop Up

Status: New
by Member DavyP on ‎05-04-2012 08:53 AM

Hello LabVIEW Experts,

 

I thought of this recently when I was setting up a test computer.  I started up my LabVIEW project file and opened up my host VI only to find that I had some broken wires... DOH!  After looking over MAX and googling a few error codes, I found that the test machine I had didn't have RT installed.  That's when it hit me, wouldn't it be great if the VI would have recognized that I was trying to connect to a cRIO chassis and gave me a little pop up telling me what software I was missing and where to get it?  Sure would have made my day easier.

 

 

P@Anand

Disable front panel control Update

Status: New
by Active Participant P@Anand ‎05-04-2012 08:33 AM - edited ‎05-04-2012 08:37 AM

When I was debugging the RT code it was getting crashed whenever I open more than one VI which has large clusters. For displaying the values in the front panel certain amount of memory is required that was the problem. In some cases it is not required to see the values in the front panel and also it is not required to open the front panel either. So it would be good if we have an option for disabling the values updation to the front panel control and I believe it will increase the efficiency even when we open those vi's. This option can be made available in the control/indicator properties and also if we want to disable the whole control/indicators present in the vi the option can also be made available in the vi properties. By default the option will be enabled and the front panel updation can be disabled by removing the check mark in the check box.

 

Front panel control.png

 

Front panel control-vi properties.png

 

I guess it is not proposed before.

When working with reentrant VIs, every time you double click an instance of a reentrant vi on the block diagram, the cloned instance is opened. This is fine during debugging but during development when you want to modify the actual code this requires that you open a clone, then CTRL+M to open the actual master vi. Much more frustrating if you have to dig several VIs deep through a highly reentrant hierarchy.

 

We have CTRL+RT Click to open the block diagram directly, how about something like ALT+RT Click to open the master VI instead of the clone.

 

Under normal development this is not such an issue but if you happen to be working with LV FPGA, just about everything is reentrant.

When you want to save a XControl, you have to save 5 items ... the savefiledialog appears 5 times ...

 

The problem is, that when you add an XControl to an autopopulating project, the savefiledialog appears 5 times,

without any memory of the last path used ! You have to browse 5 times save all elements.

 

Here some possible solutions to this problem ...

 

  1. The save file dialog should keep the last saving path in memory
  2. In autopopulating project, the saving path should be automaticaly taken from the project architecture 
  3. A special save file dialog could be build, enabling to rename and save all 5 elements in the same directory ( This solution force to save the file in the same path ... is it good ? for me i think so ! )

 

 

 

elset191

Use consistent increment and decrement

Status: New
by Active Participant elset191 on ‎10-08-2009 11:19 AM

Say I have a numeric control on the front panel whose value is 3.8.   If I put my cursor after the six and increment it (using the inc/dec buttons or the arrows) it goes to 3.9, 4, 5, 6.  It should go 3.9, 4, 4.1.

 

Mathieu_T

LabVIEW 64bit french version

Status: New
by Active Participant Mathieu_T on ‎09-21-2011 04:54 AM

A lot of customers are asking why a french version of LabVIEW 2011 64bit is not available. Is this idea take part of the future roadmap ?

heel

IMAQ VI's should support all image types which makes sense

Status: New
by Member heel ‎03-17-2010 08:31 AM - edited ‎03-17-2010 08:33 AM

Inconsistency is found in the supported image types for many IMAQ vi's:

 

For instance IMAQ ROIProfile, IMAQ LineProfile and IMAQ LinearAverages supports U8, I16 and SGL format but do not support U16 format images.

 

But, a profile along a line drawn in a U16 image should make as much sense as in an U8 image. Shouldn't it? So why is it not supported?

 

In addition, I would expect it to be easy to add an additional polymorphic U16 version.

 

These are just a few of several examples of similar inconsistency in IMAQ vi's.

 

 

Message Edited by heel on 03-17-2010 08:33 AM

These two structures can be replaced with each other, but not with a case structure. I can't count how many times I've drafted some code, then want to reuse some or all of the cases selectably at runtime. Changing to a Conditional Disable Structure is halfway there, but then I'd still need to have a project file to define and edit custom symbols, which I often don't.

loera

Auto-populate the VI Tree for Instrument Drivers

Status: New
by Member loera on ‎01-17-2013 11:18 AM

Greetings,

 

I recently took the NI Instrument Control class and we came to the topic of creating a VI tree.vi.

 

It didn't make sense that we needed to update the VI tree.vi AND the palette when we add or delete a VI.

 

I propose that there should be an option to auto-make a VI tree.vi or just a simple html page with the available VI's in your project/driver.

 

This currently makes sense since all the VIs should already be categorized in the palette.

 

Thanks,

 

-Jose

Currently we can only get the code from NI if we've purchased the stand alone license and it's double secret zipped & passworded.  The object is to select the DSC-RTE "additional" installer at "Installer build time" and build one clean package.  Our work around was to buy the customers license, download the code, and add the DSC-RTE installer as a pre or post command (or manually install before running our DSC app.)  Vision products are setup for clean Installer builds...follow their model.

LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in.  Add a header to the file to allow LabVIEW to open the file in the correct version.  This will save a lot of time and lower frustration of accidently saving a file in the newer version.

The numeric controls can be configured by specifying Min/max values ... and behaviour when going over these limits (Coerce, ignore ... )

 

This feature works fine on the front panels ...

 

But when you modify the value of such controls programaticaly using a property node ... these constraints are not taken in account.

 

It would be nice to apply the MIN/Max limits also to the "value property" (and valus signaling too)

 

 

 MinMaxNumericControls.PNG

Most of the new LabVIEW users will start programming from the scratch. They really find very hard to understand from where did this particular object (function) came from. So if the location of it is displayed in the context help it will give a better way to easily find that object from the location.

 

Ex: "Create User Event" can be displayed in context help as below

 

Location: Programming->Dialog&User Interface->Events->

 

(or in a shorter form that everybody understands).

 

Sorry if this idea has been discussed before. Or its not at all needed. For a newbie this will help definitely.

Please support the path alias NI_AB_PROJECTNAME for building an installer as it is done for building an executable.

 

When generating a new executable, the default path is ../builds/NI_AB_PROJECTNAME/Application where NI_AB_PROJECT_NAME is an alias for the name of the project. (This is only visible when viewing the text of the project file.) When creating a new installer the default path is the same one, but the project name is hard coded. And NI_AB_PROJECTNAME is not supported when I edit the file by hand.

Most time this is only an inconsistency and not really a problem. But when the project is renamed the application is deployed in a new directory, but the installer is not.

 

Please do also support the alias NI_AB_PROJECTNAME in any build target not supporting it. Overview of the targets I can build (+ supporting, - not supporting):

+ Application
+ DLL
- Installer
+ Interop Assembly
+ Packed Library
+ Source Distribution
+ Web Service
- Zip File

 

The project file I read out if NI_AB_PROJECTNAME is supported is appended.

There are times that I wanted to use a numeric constant or control as a string data type. In order to use a different data type, I would manually copy and paste the control/constant values to another data type. Moreover, if the control or constant is an array of values, it's tiring to do a manual copy of the values. Creating a vi that would convert the data type would also take time. As a suggestion, I hope LabVIEW can include in their "right-click" property box a method of converting the Path to String, String to Path, String to Numeric and Numeric to String.

 

I don't know if this is a big thing or not. Just a piece of thought.

 

 21840iAA17F180F8660DF4

We have all been enjoying the advantages and practicality of graph and charts, but when it comes to a vertical plot whe are ONLY LEFT WITH THE OPTION OF USING A XY GRAPH. Working with XY graphs involves creating our own arrays to save the history, extract from the array only what we want to show,  deal with the scales, and create a ramp array to use in one of the axis to correlate to that of the signals (basically, build a cartesian diagram). It is cumbersome and time consuming.

WOULDN'T IT BE GRATE IF WE CAN CREATE A VERTICAL PLOT BY SIMPLY DOING : RIGHT CLICK -> ROTATE ??? Is this too much to ask ??

 

Think about it !!!

Maciej_Antonik

Save all project as one file

Status: New
by Active Participant Maciej_Antonik on ‎09-16-2009 03:06 AM

Most of applications we write in LV are contained inside of a project. Saving it to disk creates a lot of files (.lvproj, .vi, .ctl, .aliases, etc) and subdirectories. This is convenient when you want to copy one VI or control to another project, but very inconvenient when sending this project to someone. In this case you have to create an archive to put everything together. Make an option to save all items contained in a project in one file.

 

Making a Windows Explorer plugin to automatically open such files as directories would be also a nice addition in this case.

 

Thanks

This Idea applies to all Libraries but my main Use Case relates to Class Libraries

 

I am not sure how everyone arranges there Classes, from trolling online it seems common that non-publically scoped methods tend to get placed in their own Virtual Folder and public methods are at the top-level. 

 For example:

 

21672i8DF9E7B8B93A8490

 

Unless my Class only has a few methods I would take a similar approach however, most of the time I like to categorize them in more detail. The reason being this is my palette from where I choose my methods, and I like to group them using the following logic so that I can get as much information visually out of the organisation / layout of the Class. I like to have the only top-level method as the constructor if there is one (so I can see that there is one or not for that Class).

I only create the Virtual Folders I need, but usually there are a mix from the follow example:

 

21674iC695C8CF5C268BEE

 

The problem I have with the current design is that I don't know whether I have scoped my public methods correctly, as I could have forgotten and they are still left not specified - which is the default when you create a new Virtual Folder

 

21676iAB6ED5F8E26BA877

 

Currently there is no way to tell the difference from the above two Virtual Folders unless you right click on them or possibly look at the contents.

This is not great as there is potential that I could have scoped things wrong which normally leads to me having to check or recheck the scope is correct.

 

21678iF61DE0BD73C6A4AD

 

As LabVIEW is graphical by nature, it would be much nicer if I could visually see a public scope glyph to differentiate it from a not specified Virtual Folder.

I selected the color green as it is a natural opposite to red (private) and has not been used yet.

For example:

 

21680iDEBCDA19ED6B9DB4

 

Therefore, my original implementation would look like the below, and I can straight away see if I have scoped the public folders correctly.

 

21682iC59F6703EC013513

 

I am sure there was a reason not to include it originally.

I am interested to why and if there is a good reason not to show this too.

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
User Kudos Count
241
58
53
50
37
Idea Statuses