LabVIEW Idea Exchange

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

My typical workflow is:

 

1) Start LabVIEW

2) Realize I have to pull\update my project from SCC

3) Explore to the project manually in windows explorer. Or open project, explore, close project, update SCC, reopen.

 

It would be nice to have an explore option in the Getting Started Window:

Explore from Getting Started Window.png

 

Either a right click menu, a button for each item or a button for the selected item would be great.

 

Same for VIs, maybe even the templates.

I normally have 32x32 png images on disk and have to copy and paste them in (and that doesn't always work well and has been reported).

I think it would be cool and fast if I could just drag and drop an image into the Icon Editor from disk.

 

I would like this image to appear as the top-most User Layer or replace the currently selected image (as per mockup below).

 

 

DD in IE.png

When wiring from inside a for loop to outside it, and the user lands the data on a singular data node (not an array or cluster), automatically set the tunnel mode to Last Value to prevent unnecessary code cleanup.

Any time I create another Y axis for my plots, I always have to manually adjust the range of each axis to get the grids on both axis to line up in a pleasant way.  For example:

autoscale.jpg

 

It would be nice if I could make Autoscale take into consideration all the axis present on the graph in determining numeric spacing to give the best looking plot.

There should be an option to fully enable optimization when building an application as to automatically remove performance impacts caused by diagram elements that shouldn't cause any.

 

As summarily declined by NI, this idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3253939#M34372

 

shows that unless you manually go over ALL your VIs disabling debugging, Diagram Disables (that are supposed to not avoid executing some code!) you'll suffer a performance impact.

 

It is preposterous to expect the users to manually disable/reenable debugging on every single VI when building an application.

 

Please add an option to enable full optimization.

 

Untitled.png

When dragging a control / indicator label or caption, if you move within a certain distance from the owning terminal the label will snap to one of a set of given positions (top-left, top-middle etc).  Outside this distance (or if the user presses the spacebar to toggle this behaviour), the label can be freely positioned.

 

The selector terminal for a polymorphic VI should display the same behaviour with regard to the owning VI icon.  A polymorphic selector is currently always free-floating.

 

Snap to.jpg

 

 

PS : Many thanks to Intaris and TiTou for their help to formulate this idea.

I'd like to suggest that the clean up tool behave the same for loop iteration and conditional terminals as it does for other block diagram objects.  I frequently end up with a little jog between an item and the conditional terminal.  I like that there is an attempt to move the terminals to their corresponding default corners, but they ought to have the same spacing from the loop frame as they do by default.

Clean Up Conditional Terminal.png

For the reasons eloquently stated here:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Defer-Panel-Updates-quot-within-sequence-frame-so/idi-p/1288952

 

defering Panel updates is both useful and a bit tedious.  You have to fetch the Panel reference, and while you are doing your presumably time-consuming operation, the entire panel is stuck.  I suggest that Deferring Updates should be a property of an individual object and not just the entire panel.  Wrap your operation with a pair of property nodes to start and stop deferring and you are all set.

 

NewDeferPNExample.PNG

Currently on waveform graph, once a plot is named it cannot be deleted (it can be made blank, but it still shows in all pull downs).  For instance I plot 3 graphs, each having 16 plots.  I then refresh data and plot only on graph of 11 plots.  My new plot names show in the top of the pull downs, but all the previous plot names still show up as well (see attached screen shots).

Please expose a method to remove plot names (property to give array of existing names and property to remove name or all names).

 

Let's say you have a class you are developing and want to reuse it in multiple targets, particularly if you work with RT targets. You want to do most of your troubleshooting and development on the PC (assuming that the class has nothing hardware-specific) and when it works well you plan to do some final testing in the actual RT target.

 

So, you create your test project, with the PC target (with the class and the tester VI). Now you add the RT target and reuse all the VIs and the class. BAM! LabVIEW locks the class and you can't make any more changes until you delete one of the targets of your project. You can't even create two projects (one for the PC another for the RT), because the class will be locked.

 

NI has an "explanation" here http://digital.ni.com/public.nsf/allkb/219A8BB7FD8EF0D9862571840053A5E9 but I find it lame, because a similar situation described in the article happens when modifying typedefs (some VIs get temporarily "broken" until you Apply Changes in the typedef editor).

 

Please do not lock classes or at least have a button/command to unlock one of them.

In most software a tab character (/t) is "visually equivalent" to several space characters (see tab list below in notepad).

 

8-30-2011 2-34-58 PM.png

 

Unfortunately in LabVIEW, a tab character is visually equivalent (in normal display mode) to 1 space character. I am proposing that this should be change to be n space character.

 

8-30-2011 2-38-00 PM.png

in LabVIEW NXG we have G Types Control which allow us to create and delete controls dynamically at run time.

Creating Controls Dynamically on a Panel - LabVIEW NXG 5.1 Manual - National Instruments 

 

Since LabVIEW NXG is deprecated (no further development) and announced that: the strengths of the NXG platform will be integrated into LabVIEW 2021(+),

 

Will that possible for us to have such G Type feature in LabVIEW? when probably?

SVG would be a great image format for icons. It would also be nice if you could use it for front panel designs or as background images. Exporting a VI as an SVG might also be a nice way of printing a VI or copying it into a presentation.

 

The advantage would be that it's scalable and an W3C standard.

 

(see also  http://forums.ni.com/ni/board/message?board.id=170&message.id=449853#M449853 )

I frequently see people posting messages about issues they have using the application builder.  They report an error number and the text of the error description.

 

Here are some recent examples:

 

Error 1 while building in 8.2

Build Error, Error 6 occurred at AB_Source_VI.lvclass:

Get Error 6 about 50% of time when building Application

Build installer error code -12 while copying distribution

 

The error description always has a long path through numerous VI's that make up the application builder package pointing to where the error occurred.  But the description never seems to give any detail about what actually caused the error.  It is often too long of a file name, or too deep of a path that gave too long of a path/filename which the app. builder VI's could not handle.

 

It would be helpful to both the people who are having the issue, and to the people trying to help on the forums when they post their message asking for help, to have some information as to where to look.

 

Maybe that information is already available and I just don't know where to find it.  Fortunately for me, I don't think I've come across this problem.  One, I haven't need to build a whole lot of executables.  Two, I keep my project folders at the root level of my hard drive, so the initial part of the path is always short.  (e.g.  c:\ProjectFolder\......)  I know if you stored projects in a My Documents directory, the initial path is ridiculously long because of the way Windows locates My Documents on your hard drive  (e.g. C:\Documents and Settings\My UserName\My Documents\ProjectFolder in XP) so you've already wasted 40-50 characters even before you give the directory name for you project folder.

 

My request:  Let's show some meaningful information in the error dialog box for Applicaiton Builder errors that can help people figure out how to fix it.

I was going to post an idea to make the Find Items With No Callers window resizable.

 

Doing a search for "resizable" returns a few ideas specific to a particular window such as the example finder. But any and all windows should be resizable. Is there any good reason that the user should not be able to resize them?

 

find items with no callers.PNG

OpenOffice last version was released 5 years ago. One of the best suites that continued the work is LibreOffice, developed by The Document Foundation. NI has a add-in for OpenOffice, but not yet for LibreOffice.

 

Please update the Integrating TDMS in Third-Party Products page adding support for LibreOffice, Apache OpenOffice, Calligra Suite, NeoOffice, etc.

                

                  A picture's worth a thousand words

 

 

aaaa.png

 

 

                                                     but,

 

 

bbbb.png

 

 

Have you ever accidentally opened LabVIEW?  I have multiple versions of LabVIEW installed and pinned to my taskbar.  I often open the wrong version since the version number is not included in the icon (see this awesome idea).  It would be really nice to be able to cancel the load rather than having to wait until the program fully launches to close it.

 

Microsoft Office products give you the option of canceling the load from the splash screen:

Excel_Cancel.PNG

 

How about seeing something similar in LabVIEW?

LabVIEW_Cancel.PNG

 

- Becky

For distribution, only package necessary libraries in installer packages built with the project. A lightweight UI, server, or client does not need a full 70MB+ installer that bloats out to a few hundred MB's once installed! A colleague has remarked that the total size of our LabVIEW application+RTE EXCEEDS the entire size of the XPe image running on the embedded computer! This becomes an issue when distributing software upgrades to places in the world without high-speed internet connectivity.

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.

 

Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.

 

The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library. 

 

I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).

 

C++ and C# default everything to private unless you declare public; I think that's true in most text languages.

 

But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.

 

In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.

 

* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.