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
candidus

Finer control of password protection

Status: New
by Member candidus on ‎02-02-2012 05:01 PM

Did you ever want to add a password-protected VI to a library or use it independently from that library? You can't do that because the password protection of the VI also forbids you to change its membership in a library.
Viewing/editing a VI and adding it to or remove it from a library are different things, however:

Imagine the following situation:
I prefer to organize my projects using lvlibs and lvclasses. Many third party libraries still come as llbs or even plain VIs. I'm not supposed to have passwords for these libraries. But these third party VIs cause naming collisions in my project. All I want is to put these things into lvlibs to prevent name collisions or build a packed
library for reuse in my projects.

Membership is not necessarily implementation hiding and thus should be treated differently. The VI's vendor should have the opportunity to decide whether changing library membership is allowed, independently from locking the block diagram.

 

A modified VI security properties dialog could look like that:

 

VISecurityPropertiesNew.png

 

A VI with these properties is password protected but can be moved freely between libraries.

 

Hi All,

 

I have recently encountered some problems when using libraries in my code whilst needing/wanting to disconnect multiple VI's from that library. I have found the process of manually selecting the VI's for disconnection to be rather tedious and time consuming (especially if they have enums and subVI's associated with them), I would suggest that perhaps the option of "disconnect all VI's from library" could possibility. After a brief discussion with some of my colleagues, some of which are very experienced developers, I have found they are reluctant to use them for this and various other reasons. I have managed to find a workaround for the solution on LAVA with this handy little script. I was surprised this functionality was not included in the development environment. Any input from other users with regards to the pro and cons they have encountered when using the libraries and other suggested workarounds would be greatly appreciated. Thanks!

Daklu

Additional glyphs for project explorer

Status: New
by Active Participant Daklu on ‎09-12-2009 08:29 AM
I like the glyphs in the project explorer window that indicate the scope of each vi.  I would find it extremely helpful if glyphs were added to indicate a VI's override status.  (Must override, overrideable - normal dynamic dispatching, and not overridable - static dispatching)
jwdz

Display VI version in Tools bar For any vi

Status: New
by Active Participant jwdz on ‎10-14-2010 08:04 AM

Display VI version in Tools bar For any vi

 

vi.png

 

My use LabVIEW 2010,Often saved a vi(8.5) as high-version .

 

Alternatively, when saving the vi, the programmer could be proposed to choose the former LV version.

 

Sorry ,My English no good.

My suggestion is a change to the UNDO function.

PROBLEM:

A common annoyance is when making a large number of changes to the block diagram that fundamentally alter the way a VI works and then you go to the front panel and set up a few default values before you press play. You then find that the code doesn't work anymore so you then try to undo the changes... You then find that the undo only undoes the changes to the front panel and not the code that really matters. not you have to manually recode what you had before or reload from disk (hopefully you haven't saved yet)

 

Solution:

My proposal is to have 2 separate undo functions - One for each edit screen ie Block diagram, and front panel.

see the diagrams below.. the shortcut keys can be differet - this is just an example and it could be implemented differently. also an icon could exist on the menu.

Block diagram UNDO.png.

 

Likewise for the Block Diagram

 

Block diagram UNDO.png

 

 

 

Here are some options to consider:

Method one.

The UNDO function will work differently depending whether you are in Front page view or Block Diagram view. - but the global undo functions the same as it always has.

Method 2.

Have the UNDO function work differently regardless whether you are in Front page view or Block Diagram view - but you must press the correct button on the menu or shortcut keys (ie CTRL + Z + F for front Panel or CTRL + Z + B for block diagram) or CTRL+Z for Global UNDO which will function the same as always.

Method 3.

Don't have a Global UNDO - and instead the UNDO button will only UNDO the changes on the front Panel or the Block diagram depending on what view you are currently in.

 

Perhaps these options could be set under "tools/options" etc - not sure what tab would be best.

 

I favour Method 1 or Method 2.

Note: the CTRL + Z + F for Front Panel and CTRL + Z + B for Block diagram is just a suggestion. but something similar should work...and likewise for the redo functions..

 

Hopefully this is clear.

Steve

JackDunaway

Selectable Class Data Member Scope

Status: New
by Trusted Enthusiast on ‎10-12-2010 07:39 PM

Currently, a class is created with a Class Private Data Cluster. Each data member of that cluster is scoped exclusively to the owning class. For access to these data members outside class member VIs, getters and setters (accessors) must be established individually for each element. These accessors can then be scoped accordingly, allowing access to the private class data through the accessor VI, or in 2010, through an accessor Property Node.

 

Quite frankly, I like the IDE interface for accessing class data members using Unbundle/Bundle by Name. This feels natural for LVOOPers who have a background with clustered typedefs (which means everybody). Unfortunately, this method of data access is reserved for callers within the scope of the class data. Currently, since all class data is private, you can only use Unbundle/Bundle within Class Member VIs themselves.

 

I would suggest an options interface for setting the scopes of Class Data Members. Having non-private data member scopes has benefits:

 

  1. Obviates all the piddly accessors clogging your project tree and SCC server
  2. Allows quick visual recognition that a data member is being read/written directly (no data transformations were snuck into the accessor)
  3. Cleaner interface for callers of the class using the Bundle/Unbundle
  4. Best of all, saves considerable development and maintenance cost
Here's an example of what the Data Member Scope Configuration screen might look like:
 
ClassMemberScope.png
 
Note that clusters can have "Custom" scope, which means the cluster's elements have different scopes. Also note that when a cluster's scope is set explicitly, it's members inherit the same scope and cannot be set (note how 'x' and 'y' are greyed under 'Center of Mass'). The default behavior (which is equivalent to today's default scope) is for 'Class Data Cluster' to be 'Private' with all descendants greyed.
This Idea is one product of a discussion which has taken several routes.

Hello,

 

The deletion of a Conditional Disable Symbol has no effect on the Conditional Disable Structures which use it.

 

This is very dangerous because the Conditional Disable Structure ignore the deleted conditional disable symbols and the default case is used.

 

It should be nice, in case of Conditional Disable Symbols deletion, to make "unexecutable", all Conditional Disable Structures which use it.

 

Thanks for reading.

 

Manu.

 

I'd love to see a handful of built-in false-color colortable choices for the Intensity Plots.

 

I know there's programmatic control over these things - I wrote my own 4-5 years ago. But the black-blue-white should be one of several common selectable colorschemes.

 

I labeled my own as:

 Greyscale B->W

 Greyscale W->B

 X-Ray

 Yellow Hot

 Rainbow

 Rainbow #2

 Fluorescent (green)

 Blue Red Green 

 Planet Earth

 

Perhaps one of the front panel (and Property node please) off of the Z-Axis submenu, listed by title.

 

I also have the ability to invert top/bottom or choose the color-inverse (photographic negative) for even more colors. 

 

Attached is a sample of some common colortables I routinely use.

2nd attachment is a snap of the VI I use to create the colors based on colortable constants.

3rd attachment is my messy but functional code (Block Diag of attachment 2)

 

Cory_K

3D scatter plot

Status: New
by Active Participant Cory_K on ‎10-06-2010 08:26 AM

Rather than a surface plot, it would be really nice to have a 3D scatter plot.

Right now, you have to pass a 1D x-array, 1D y-array, then a 2D z-matrix.

This is very non-intuitive, and takes quite a bit of poking around to figure out why this is the case.

 

It would make much more sense to be able to pass in a cluster of 3 1D arrays of equal length, the same way you do with an XY graph.

In this case, it would be an XYZ graph.

EricC.

List the lvlib hierarchie

Status: New
by Active Participant EricC. on ‎05-19-2011 04:03 AM

In a complexe project, when you make Packed Librairie (lvlibp) or dll it is very important to compil your lvlib in a good order.

(from lvlib with less depencies to lvlib with more depencies)

 

But we don't have a way to see the lvlib hierachy

(we have only vi hierarchie, class hierarchie)

 

 

I'd find it really helpfull, if there would be a possibility to create a new "value change" case in a event structure by right-clicking the control-terminal in the block diagram. If there is no event structure in that VI, the menu entry ("Create event") should be greyed out or be removed.

Today if you want to change for example a number of controls to indicators or constants you have to do it one by one. The only option you get when selecting multiple controls and right-clicking is "Properties"

Multiselect Props.png

Wouldn't it be nice to be able to change multiple at a time?

 

Multiselect Props.png

 

Option for turning off indexing for TDMS

Status: New
by Member Gleichman on ‎08-26-2009 03:42 PM

" ... when a TDMS file is open, LabVIEW will create an index structure in memory that is used for random access to the file. The built-in LabVIEW TDM Streaming API will always create this index, even if you're just writing." - Herbert Engels

This feature will cause an apparent memory leak if your program periodically writes to a TDMS file over a long period of time. 

 

Feature Request: 

Disable indexing option for "TDMS Open.vi"

It's very rare for me to deal with large arrays, so it's seems very retarded when I'm debugging to 

find VIs have not retained their values. I must turn on the "retain values" and re-run and go through 

a huge test sequence again to trigger the problem.

 

All to save 100K of memory, when I've got 2G to through around.

 

How about a global setting "RETAIN WIRE VALUES" and per-VI setting to override the global.

 

Wouldn't take much...

 

 

I could create cleaner diagrams faster if I had an option on the output tunnel of a case structure to use previous value.

 

LatchCaseTunnel.png

When debugging an xcontrol it is annoying to constantly go back to the xcontrol .xctl window and to unlock the library for editing by right clicking on the .xctl icon and selecting it from the drop down menu.  I usually have lots of windows open for debugging and finding the control window, and then right clicking and selecting can get tiresome very quick.  It would be nice if vis that were a member of the xcontrol had a button, perhaps next to the context menu button, that you could click on for unlocking the control for editing, and similarly the converse, applying the changes to all instances.

The Proposal:

The XY Graph should be able to switch from a Linear scale to a Logarithmic scale and back again without any fuss. While the VI is running.

 

How it should work:

XY Graph Log Scale 2.png

Notice that the linear scale changes back to -2500 -> 2500 when switching from Log to Linear.

 

 

Here's how it currently works:

XY Lin-Log-Lin.png

(A Hobbit's Tale)

2 things to notice:

1. The Log scale did not automatically take the absolute value of the Y values. This should be optional, with both a Properties Dialog option and with a Property Node available to edit.

2. When changing back to the linear scale, the minimum value remains at 3. It should return to the original autofit scale, which LV chose to be -3000 to 3000.

 

Why This Should Be Done:

Currently, the work around takes up quite a bit of BD space, needs an event structure, and can be memory intensive. If you have data that you want to view on both a linear scale and a logarithmic scale arbitrarily, you need to have, at the very least, a case structure (or Select) that takes the ABS if the scale changes to log.

 

Here's the simple, made-in-10-minutes workaround example of what I'd like the XY Graph to be able to do natively:

XY Lin-Log Example VI.png

 

 

I don't think that there should be a need for extra code just to switch between linear and logarithmic scales nicely.

X.

LabVIEW Vision: Image ROI Features

Status: New
by Active Participant X. on ‎09-28-2010 01:26 PM

1) Allow tilting ANY type of ROI, not just rectangles. For instance, the user draws an ellipse or a freehand path and is allowed to tilt it anyway he/she sees fit.

 

2) Allow RESCALING ANY type of ROI. By this I mean provide the user with handles on the bounding rectangle of the ROI and allows he/she to resize the enclosed ROI.

 

3) Provide a more intuitive definition of ROIs. I know this will break backward compatibility, but the current (cryptic and undocumented) way the ROIs are defined with an array of I32 is useless. We had to break backward compatibility when moving from horse carriage to engines.

 

4) Restore the option to show ROI ID present until LV 8.5 (and extend it so that they can have "captions") [BTW, this is clearly a case of NI breaking their own motto of preserving backward compatibility]. I know this is something that can be emulated using overlay. I am just suggesting to promote it as a basic built in feature.

 

My 4 cts,

X.

Luke H

Driver Dependencies for Packed Project Libraries

Status: New
by Member Luke H on ‎09-27-2010 02:23 PM

Packed project libraries are new with LV 2010 and seem to be a great way to share code.  One idea to make them more user friendly for the end user of the library would be something that would give the project library developer the ability to specify driver dependencies for their library. 

 

If the end user of the library did not have the right drivers installed, they would receive a warning or maybe a broken run arrow if they tried to use it.  The warning could be very descriptive by telling them exactly what drivers they are missing.  This seems like a better solution that just getting all these arbitrary errors because LabVIEW can't find subvis called by the packed project library.

 

Here's a mockup of what the window for this might look like in the packed project library build specifications (borrowed from the additional installers window).

 

packedlibrary.png

Darin.K

Property "Eye dropper" tool

Status: Duplicate
by Trusted Enthusiast on ‎08-14-2009 01:17 PM

I would like a FP tool that is similar to the eye dropper except that it functions on a control's properties rather than color.  Ctrl-click on a control to sample the properties (data range, default, representation, mechanical action, etc.) and click on a different control to change its properties.  If the controls are different, the click is ignored.   When one of the few tools we have is equivalent to right-click, I don't think we risk clutter by adding a few more.

 

Or, LV could allow some property changes (besides font) to multiple selected objects...

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
Idea Statuses