LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

pop up comment on Block Digram

View All (4)

View All (1)

A big project can take more than 10 minutes to load, especially on an older computer. If subVIs are missing, the Ignore Item and Ignore All buttons become available when the first VI is missing. This can happen anytime during the loading and the process stops until the browse box is canceled and then the Ignore All button is pressed.

It would be better if the Ignore All button was always available where it can be clicked at the beginning to insure the project is loaded in the expected time.

Ignore All.png

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number. For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later. Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions. However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

Changing VI connector panes
Renaming or moving VIs on disk
Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs. Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI. This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

The "new" File-Dialog (alignment)

below, here is the "old" File-Dialog

But NI advises this :

the problem is that this "new" File-Dialog isn't aligned like the "old" one

Please ... align this "new" File-Dialog-Express-VI"

(thank you)

Recently, I discovered an annoying "feature" of LabVIEW: if you limit the data entry of a floating point numeric to a maximum value with coercion enabled, entering NaN to that numeric will be coerced to the maximum that you set in the data entry dialog.

I already reported that as an unexpected behaviour, but after some more thinking, I dare to go even further and propse:

allow the blocking of NaN in floating point numeric data entry

The logic needed should not be much more than a finger exercise, as string controls already allay to discard CR/LF with the "limit to single line" property.

Best regards,

Sebastian

View All (3)

When installing a new version of LabVIEW, I always find myself resetting all of the options I previously changed from the default settings in the Tools -> Options menu. This means I have to spend my time remembering what options I changed and where in the Options menu I need to change them. It would be nice if a newer installation of LabVIEW looked at the older version's Options settings and then applied those settings to the new installation.

The same idea applies to how I configure the palettes on the block diagram. It would be nice if newer installations looked at how I configure my palettes and then set them up the same way.

With these changes transitioning to a newer version of LabVIEW might be even more seamless for users that change their settings from the default settings.

View All (5)

Add an option to remove items in memory

After deleting items I don't want in the project, or loading plugins in a plugin architecture, I want to remove them from the LabVIEW memory. This is not possible now, as they go into Dependencies->Items in Memory.

The only way to do this now is to close and open the project, which over a large Plug-in architecture project is a real pain.

Ideally, I would like to right click the folder and choose "remove from memory". However, any option that allows this would be good.

Thank you!

Danielle

View All (4)

The "right-click...replace" option has few choices, typically the home palette of the current selection if available and "All Palettes".

Quite often, I need the entry "Select a VI...", all down at the bottom after selecting "All Palettes".

Suggestion 1: Add "Select a VI..." to the first menu, see image.

Especially when benchmarking or trying different algoritms, I often like to replace the current VI with another VI that is already in memory.

Suggestion 2: Also add a "VIs in memory", which would allow picking from list of all VIs in memory (except things located in VI.lib or in the standard palettes).

Here's an image how it could look like:

Message Edited by altenbach on 07-05-2009 09:35 PM

Splash screen for application

When you mass compiled, all VIs in the directory tree get recompiled. When you hold CTRL and SHIFT and click the run button on a VI, it forces a recompile of all VIs in the call chain.

However, when you CTRL-SHIFT-Run, all you SEE is a busy mouse; it would be really nice if you could get a popup windows (the same as when you mass compile) showing what's going on, and giving options to cancel... it would also be nice to be able to specify a log file and how many VIs to cache, same as with mass compile...

It could be the same popup with a different title...

Feedback nodes can reside entirely inside one case of a case structure. This simplifies coding if feedback operations are limited to one single case. Unfortunately, there is no easy way to retain the output once the loop has finished if the last iteration executes one of the other cases. As a result, we might see local variables or even indicators inside the case containing the feedback node, defeating the "in place" purpose. For a "wired" solution, we need to place the feedback node outside the case and wire across all other cases (image top).

I propose an output terminal that sits on the output edge of a loop and contains the contents of the feedback node at the time the loop finishes. Typically that would be the edge of the same loop that contains the initializer terminal (image bottom), but it should also be available for globally initialized feedback nodes and on other loop boundaries surrounding the feedback node (selectable).

I am sure this idea needs to be worked out in more detail, so this is just an initial concept. 😄

Message Edited by altenbach on 06-16-2009 09:34 AM

View All (2)

It makes no sense (from a Software Engineering and Process standpoint) to force (and store) an absolute path for a build destination directory, in the project. What if a group is sharing a project but each developer prefers to have their files located in a different folder?!!

I recommend NI consider replacing the line of code in LabView that is checking for the presence of an absolute path for the build folder with on that does: "If user entered an absolute path, use it; otherwise, prepend the current project location to whatever (relative) path the user entered before building."

History for insert

In a big project I needed to insert a function at several (read "more than hundred") places.

How much would I have appreciated a history which gave me a direct access to this function without the need to go to the specific functions palette again and again !

This would have saved me a lot of time... and made this annoying task a little bit less annoying !

LabVIEW should memorize at least the last inserted function/VI but a history of four or ten would be much better.

The history could be implemented either with an extra menu (see below image) or by listing the X last inserted functions/VIs right under the All Palettes menu entry.

The incompatible functions/VIs for the wire type should be grayed out or, even better, the history should be contextual and list only the compatible functions/VIs.

View All (2)

Create Snippets for Previous Version

As mentioned in this post, and elsewhere, it is very helpful on the forums to (1) post images and (2) post code that is usable by the masses (typically 8.6+). Snippets are a useful way to post both images and code (for 9+ officially and earlier with a few tricks like the Code Capture Tool). One downside is that if you are working in LV10 your snippet is not usable in earlier versions. It would be nice to be able to Create a Snippet for a previous version in one operation.

I do this myself, for example:

Makes life easier for both the posters and the responders on the forums.

View All (3)

View All (1)

LabVIEW Idea Exchange

pop up comment on Block Digram

Execute project-based cfg with VI Analyzer API

Ignore All should not be greyed out until the first VI is missing

VI Migration Independent of LabVIEW Version

"Is Path and Not Empty.vi" Should be Malleable

The "new" File-Dialog (alignment)

allow blocking of NaN in numeric data entry

New LabVIEW Installation Retains Options

Replace/Insert/etc context menu should show palette for wire element type as well as Array Palette

Add an option to remove items in memory

More options for the "right-click...replace" menu.

Diagram Constant Representation visualisation

Splash screen for application

CTRL-SHIFT-Run should display progress windows the same as MASS COMPILE.

An output terminal for feedback nodes that mirrors the initializer terminal

Application build destination directory should not require absolute paths

Shorten the Drop event "Available Data Names" element

History for insert

Create Snippets for Previous Version

Easy Access Button to Enable/Disable Debugging