LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

The current interface for DLLs does not nicely accommodate C++ classes.  For instance, there is no inherent mechanism for passing in and out of DLL calls the reference to an instance of a class.

Allow the configuration portion of DLL nodes to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).

Invoke nodes can have lots of optional arguments, resulting in their taking up a lot of vertical space.  I would like to recommend that the arguments portion of Invoke nodes be resizeable, allowing the developer to select the optional arguments to be displayed on the block diagram and, hence, have more control over the layout of the block diagram.

 

Consider the Save-As Invoke node from Microsoft Word:

 

Current Microsoft Word Save-As Invoke Node

 

which gets longer with each new version of Word.

 

Now imagine being able to show just the optional arguments that are needed:

 

Just the Optional Arguments that are Needed

 

And, as an added bonus, this Invoke node would not break when the VI is opened in a development environment that has a different version of Word with the same exposed optional arguments.

Many built-in functions have the growable ability. Essentially a function that accepts an array of data in scalar form, this saves the step of building an array prior to wiring a terminal.  I would like to select any  1-D array on a connector pane and mark as growable.  Then when the vi is used as a subvi, the icon would have the growable ability.  This could have been used as for example for making a growable error handler or implementing new compound math functions.  I know this is probably hard to do and might be possible with xnodes but I dont have time to learn this.  It is useful for making reuasble toolkits which look more like the native G functions

I Have already designed a program in Visual studio 2008 to control the movement of some linear stages.  In the future we want to create the program in labview to integrate it with our other program's which run labview.  Is there a tool which can convert the VS straight to a labview VI?

Ok this idea would be trivial for NI to include in 2011.Heck I could do it.

 

The idea is simply to include the JKI state machine in File/New/Design Patterns. It is BSD code and I am sure that JKI wouldn't mind anyway.

 

I must admit that I have an ulterior motive. If this were included in the NI distributed templates then I could use the JKI state machine for my CLD exam. And so could you!

 

Now let the kudos start rolling in so NI will take notice.

How comes these 2 palettes avec merged in one called "Vision and Motion"?

 

I'd rather have a Vision palette and a Motion palette.

Plus, if you only install Vision (and not Motion) then the palette name is "Vision and Motion" but in fact it only contains vision functions, so the palette name is inadequate.

 

See here :

Clipboard02.png

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

In LabVIEW 2009 one could right-click on a VI, for instance, in the project Files view and select a Delete from Files option.  (It didn't work perfectly--in particular, LabVIEW didn't always delete folders from disk, but it usually did work for individual VIs.)  NI removed this option in 2010, leaving the developer with the task of deleting files manually through the OS files view.  (This isn't the end of the world, of course, if a developer doesn't use integrated version control--and we don't currently but only because LabVIEW does not properly support integration with Subversion--but it is a significant inconvenience.)  This option ought to be present once more.

 

In particular, this function is absolutely required if LabVIEW makes a claim to provide integrated support of version control.  On that note, the current client (Pusk Ok SVN) LabVIEW supports for what is probably the most popular version control provider (Subversion) among its customers does not even claim to support file renaming or deletion (http://www.pushok.com/soft_svn.php), while a third party plug-in (http://jkisoft.com/tortoisesvn-tool/docs/) claims to support this behavior only for VIs and Controls (not, for example, LabVIEW class files).

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

When building reusable components I create a set of classes that work together to accomplish some larger goal and put them all in a lvlib.  Sometimes some of those classes are optional--they are not required by the library for it to work but they can make it easier for users to use the library for certain tasks.  These optional classes belong in the same namespace as the library.  One behavior of libraries is that they load all inner libraries.  When the inner library is a class all the class member vis are loaded, which wastes time and consumes resources when the classes aren't needed.

 

My current options are:

- Don't include the classes in the library.  Consequence:  I run a higher risk of name collisions and there's no continuity.

- Put each optional class in its own independent library.  Consequence:  Namespace pollution and a reliance on an arbitrary convention to figure out what libraries should be used together.

- Put the optional classes in the library.  Consequence:  Resources are used needlessly.

 

Usually I do the last option as it provides a more cohesive user experience.  I wish I didn't have to.  An lvlib is a functional grouping of code.  A namespace is a logical grouping of code.

 

To be explicit, I would like to be able to define namespaces for each library such that:

- I can have a single namespace that crosses multiple lvlibs.

- I can have multiple namespaces within an lvlib.

- I can add libraries to a namespace without rebuilding all the libraries in the namespace.

- Loading a component with a specific namespace doesn't automatically load all sub-namespaces.

 

Futher,

- I'm not requesting the ability to separate a single class into multiple namespaces, nor do I think that's a good idea.

- I don't mind the class name being part of the fully qualified namespace.

 

There have been several ideas proposed to alleviate accidentally savings vis in the wrong version of LabVIEW. While useful, I think the main problem is that LabVIEW doesn't use the information it reads from the file to preserve compatibility. I'd like to propose here that LabVIEW introduce compatibility modes for previous releases in which LabVIEW will break a VI if a feature is introduced that isn't supported by the compatibility version. It will essentially be a built-in, seamless "save for previous" mode. 

 

By default, LabVIEW will load a VI (hierarchy) in a compatibility mode for whichever version is was saved in. If the user tries to make a change that isn't compatible, LabVIEW will alert the user and the user can tell LabVIEW whether it's ok to save to a newer version that supports the feature.

 

The level of alerts can be configurable, of course.

 

Related ideas:

Version-aware LabVIEW launcher

Add header to LabVIEW file to contain the version of LabVIEW

Display VI version in title bar

Version independent Source Code Saves

LabVIEW has shipped with an Express VI which supports the ASCII LVM format since version 7.0.  However, there is no other way to access LVM files from LabVIEW, short of burrowing into the Express VI and using the subVIs.  Doing this leads to problems, since the subVIs have changed a few times.  In addition, the Express VI does not support all the features of LVM and makes accessing multiple data segments somewhat nonintuitive.  We need an API for LVM, ideally object based, so features like the special block can be easily extended by users.

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

 

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

 

21826iFF181EE2E7ECE408

 

This would remove one step required for most use cases, speeding up my development experience.

I really like the changes to the Create Data Member Accessor Screen in LV2009 (and LV2010).

 

I like the Place new accessors in this folder logic.

One thing that would be cool to extend on it would be if the screen allows you to set the scope of a new Virtual Folder at the same time.

 

21684iC82E6A87291349BB

 

This would save time as you would not have to right click and set the scope of the new Virtual Folder from the Project Window the first time it the Virtual Folder is created.

If the Virtual Folder already exists in the Class then this option should be grayed out and disabled.

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.

At the moment you can Register for Events using a Cluster of Refnums.

But you cannot Destroy User Events or Unregister for Events in this way.

 

This approach allows for you to scale your application without the need to change the code that handles Registering Events.

It would be very convenient to be able to close references in this way (using a Cluster of Refnums) too, as per my illustration below:

 

21670iEFD0527198796259

Support LabVIEW-UML integration.  Integration means supporting code generation from models and reverse engineering to models.  The UML tool must support the latest UML specification from OMG.  (This includes the specifications for interoperability.)

 

Other considerations when selecting a UML tool should include:

UML features and ease of use of the tool.

Support of SysML.

Integration with version control.

Additional features of the tool.

Cost of a license.

Size of user base.

 

When I want to insert a line of text in the Enhanced Icon Editor of an existing VI it usually means I have to overwrite my existing text or cut and paste it.

 

I.e. If I simply want to go from this:

 

21203i5E96ED314B36205F

 

To this:

 

21205i0BA9C1C27BE039D4

 

It's not that easy and it could be much quicker.

 

I would like to be able to Right Click (or a similar method) on the Lines Cluster and select "Insert". 

This would insert a blank line and move the Line Text and Line Colors accordingly, preserving existing settings thus allowing me to easily edit the above icon's Lines quickly and easily.

 

Hello,

 

I would like to suggest that LabVIEW support HDF5 for data format, file storage and data transfer.   I would to suggest the support include maintenance to coincide with new and future versions of HDF5.

 

Thank you.