LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Allow labeling to the probe

When debugging labview application. If we use lot many probes at a time then it becomes to complicated to understand which probe is which one.

The main reason for confusion is probes are named by probe number and its data type.

In LabVIEW we can label the wire by right clicking on wire and selecting the visible items>>label. However this label name is not used in probe. This name should be used as probe name.
Naming each and every wire is not possible, so in probe window user should be able quickly edit the name of probe (using F2 as shortcut key) to give name of his choice

Also when I manually name the probe it should update the label.text property of the wire

View All (2)

Error in terminals that are ignored/passed through by the VI without preventing normal execution should be marked differently in my opinion.

I've lost count of the times where I have to keep reading through the help files to check a function's error in behavior.

Examples: Release Semaphore, Close reference, Release Notifier

Then there're the functions that I have created that exhibit the same behaviour. People reading won't be able to tell at a glance if the error prevents execution when called from another function. As a quick fix I label the terminal 'error in (pass through)' or 'error in (ignored)', but it's not ideal.

Bonus points if this can be marked as such during development and the behaviour enforced/checked at compile time similar to the following (I know it will be difficult to reliably implement, so maybe warn instead):

View All (1)

Service Packs

View All (1)

Cleanup diagram - Improvements required

Cleanup diagram is not much used (Personally I allign the diagram myself manually). But if we have few improvements with the tool we can use it atleast in sub vis more often.

At present the Cleanup diagram tool introduces unncessary wire bends eventhough it can be avoided. So it would be great if this is taken care properly and unncessary wire bends are removed.

Manually alligned without wire bends

Wire bends are introduced once the Cleanup diagram is done.

Download All

View All (4)

Disable the context help in executables

Changing the connector pane of a subVI requires relinking to the subVI in all callers. Until we relink (right-click...), the subVI is bleached and the caller broken.

When refactoring old code, subVIs often contain odd connector panes and one might want to change to a more typical pattern (e.g. 4-2-2-4), and reassign connectors to established policies (e.g. error in/out at the bottom corners). Also, sometimes there was poor planning and we need just one more connector terminal.

Currently, relinking to a subVI clears all "subVI node setup" settings. This is unexpected and I suggest that these settings are retained instead.

Example scenario:

I was working on some very old code (originally from LabVIEW 4.0 :o), and there was a single instance of an interactive subVI that was set to show the front panel when called and close afterwards ((in the subVI node setup of the caller, not in the VI itself). This subVI was interactive and required user interaction to complete. It had some odd connector pane (four horizontal terminals all the way across the icon, top as input and botton as output) and I wanted to change it to the standard 4-2-2-4 pattern. After changing the pattern, I did some switcheroo on the connectors, correctly rewired in the caller, rebuilt the app and deployed it to the PC controlling an instrument. (I could not test run locally because it required the presence of the instrument)

Bam! Triggering the subVI call no longer showed the front panel and since the caller required the subVI to return before continuing, everything was locked up. I had to kill the build executable via task manager. Now the guessing game started, trying to figure out why the app would lock up. Since I also did a few minor changes elsewhere, It took me a while before realizing that I should maybe look at the "subVI node setup". Sure enough, all settings were cleared. These settings were retained during 20 years of version upgrades and I did not expect them to change behind he scene and without warning :D.

Anyone can easily verify that relinking to a subVI will clear all settings in the subVI node setup. Would anyone expect that? Probably not!

IDEA SUMMARY:

Relinking to a subVI should retain the existing "subVI node setup" settings.

The existing settings are most likely also appropriate after the connector pattern has changed. This is the expected bahavior. There is no reason to clear these settings. Thanks for your votes!

View All (3)

I often open a subvi while the calling vi's are open. I make a few changes. I try the changed code and decide I prefer original. If I try to close the vi without saving it is not possible. I must select "defer decision" to save. Then when I later close the main vi, I am asked to decide whether to save the subvi or not. By then I may have forgotten that I did not want the revisions saved or simply use the apply decision to all by mistake. Allowing a close without saving at anytime would be most welcome.

I'd like to see the Destination Path in the application builder have an option to be a symbolic path based on the project directory (the direcotry where the project file lives) rather than an absolute path. For instance, if the project path (in our case, a local Git repo) was "SS10 Src Repo" and there was a subdirectory called "Builds", it would be nice to NOT have to specify "C:\users\xxx\Desktop\SS10 Src Repo\Builds" as the destination path, but rather check a box to say "symbolic path relative to Project Dir" and simply specify "Builds". If the repo is moved or renamed, all those destination paths in each project file need to be edited.

One reason for doing this is to locate executable that are built from the project, and called from project files via System Exec.vi. At runtime you need to find the executables (assuming they are localized and not in the PATH) and you can use the Application Directory file constant to figure out where your executables SHOULD be (relative to AppDir). But configuration to specify their location in each project file using an absolute path is a b**ch... it would be great to not have to edit all the dest paths in each .lvproj each time we check out the repo on a new machine, or by a different user...

View All (1)

View All (3)

CVI has this feature, almost every other UI library has it, too.

Only LabVIEW is missing the simple option to limit the number of characters that can be entered into a string control.

I know, it is possible to do this programmatically. But this is always a piece of extra effort I have to undertake, while the solution never looks really satisfactory.

Usually all I can do is react to the value change event of a control and cut what's too much. But this means the user sees some flickering, since the character is first drawn and the corrected version is drawn at a later time.

Side notes on how I think this should be integrated:

This should be an additional property for all string controls. For existing controls from older versions, the value should be set to it's default (-1), which means unlimited.

If activated, this feature should also cut the strings in VI input terminals to avoid "special behaviours" in this case.

Today, when you create a case structure and wire a string to it, the case structure becomes case sensitive. This may have been relevant in the 1970s, when every bit was important, but these days I'm guessing that in at least 95% of the cases the structure should be case insensitive, although most people are probably not even aware that you can change it.

So, why not make the structure default to being case insensitive instead of case sensitive?

Actually, I would possibly even suggest removing the case sensitive option altogether, but this is probably required for some things and would break existing code which relies on this.

Message Edited by tst on 20.04.2010 04:43 PM

View All (1)

Anonymous Method Structure

If code is running and one happens to leave a modal VI open, or opens a modal VI in the middle of a running piece of code, then the LabVIEW environment freezes-up and dis-allows any interaction with the code. It will be great to have a set of Key Strokes to re-set the code if this happens. The only way that I know of now is to hit [ALT + CTL + DEL] and killing the LabVIEW process. This ends up loosing unsaved work and requires a restart of LabVIEW.

Regards

Anthony L.

align the upper input of "swap values"

View All (1)

Currently, if a new version of LabVIEW comes out with new shortcut menu plugin or a quick drop shortcut, that is written in LabVIEW the only way to have that added for older, still supported versions is to save them to for the oldest version, and copy them to the respective folders.

I wish, that the new features in these categories would be available trough download for the supported LabVIEW versions for everyone that has a license.

I would love, if these were separated into their own package, that is a dependency of the LabVIEW installer, but could be updated later from the package manager.

View All (3)

LabVIEW Idea Exchange

Allow labeling to the probe

Standard marking for when 'error in' is ignored/passed through

Service Packs

Cleanup diagram - Improvements required

XNET database editor show meaning of values

Disable the context help in executables

Relinking to a subVI should retain the subVI node setup settings

Add an "Explain Error" pop-up menu on the conditional error probe

Allow a subvi to be closed without saving at any time.

Add Option to Make Destination Path in Application Builder a Symbolic Path (relative to the Project directory)

Search option for finding a case in Case Structure

Provide a tooltip for Recent Project entries to see project path

Option to Limit the Number of Characters in a String Control

String case structures should default to being case insensitive

File Properties of VI show "VI Version" and "LabVIEW Version" meta data.

Anonymous Method Structure

Need a Way to Exit LabVIEW Code if a MODAL Window is Accidentally Open(ed)

Option to place duplicated VIs in same virtual folder as the original

align the upper input of "swap values"

Make the new shortcut menu and quick drop plugins available trough download for older versions