LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

When I need to access project-related non-LabVIEW files in my VIs, I usually write code like this

File path relative to the VI path in LabVIEW 2019

I can't afford to use absolute paths because my collaborators don't set up source code control on their computers the same way I have it on mine, and I am fine with that.

Writing this type of code is tedious. I have to place four nodes and three wires between them to get one path. On top of that, coming up with the relative path requires either browsing the absolute path, and deletion of the portion of that, or copying and pasting paths from the OS.

I would like to express this with a single node. It could be a mode on the path constant, with some visual difference to convey that it's doing something else. Here is one idea

Path relative to the directory that contains the VI

You'd be able to browse the path the same way you do today, and change the mode with a right-click and/or configuration dialog.

This idea was inspired by TestStand, where you can typically indicate whether you want a path to be stored as absolute or relative.

View All (3)

When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!

You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...

This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.

Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...

Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.

Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.

And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:

By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?

Best regards,

Sebastian

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

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.

Disable the context help in executables

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)

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.

View All (4)

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!

A graphical programming language deserves to have great graphical tools representing the design of big applications.

It is possible to use scripting to understand if a method of a class has another class as input or output terminal and to know if a class composes another class in private data. The only thing I cannot do right now myself is to show this information in Class Hierarchy window. Representing the usage and composition relationships only requires parsing through the project once, and then every time it changes.

I am right now using a script to parse through all project classes to understand which have what relationships, which are actors and which are messages and I draw a Plant UML diagram from that. The intermediate step is to generate Plant UML text, but this should be integrated into LV.

https://forums.ni.com/t5/LabVIEW-APIs-Discussions/Project-to-Plant-UML-Diagram-Script/td-p/3984499

Please improve the readability of object oriented project with additional tools for LabVIEW. This is especially critical for NXG, where the currently the ability to understand an OO project is even more limited than LV19.

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)

When running NI web server, the domain URL of the server will always redirect to the NI web server (or Systemlink) login page. Every Labview-built web application/webservice has a name and therefore must have a path (like: https://example.com/mywebapp)

I would like to be able to set a default redirect in the NI Web Server configuration to redirect the domain url to the default web application on that server.

It can probably be done in some Apache config file, but those a really managed by the NI web server configuration and are easily corrupted. My forum post about this issue has not yet been answered.

View All (5)

How many splitter bars does this VI have?

The answer is three, but they might not be where you think:

It would be useful if LV showed the splitter bars more clearly in edit mode. Switching to run mode would display them "correctly".

This idea is similar to Show hidden controls as "ghosts" in edit mode and the same basic concept can be extended further. If anyone has anything else which is difficult to see and can be shown more clearly in edit mode, why not add it as a comment?

View All (3)

align the upper input of "swap values"

View All (1)

In Range and Coerce for Waveform

View All (4)

View All (1)

This idea is an extension of the idea given here How about a Front Panel Cleanup?. We could have a more generic front panel clean up which doesn’t really worry about the connector pane patterns (and if needed automatically connects the connector pane as well)
Here is the idea->
Often while writing a VI we create controls and indicators from the block diagram itself rather than going to the FP and creating it. Also we copy Control and Indicator terminals from other VIs and type defs and directly drop it on the block diagram than the FP because BD is what we are usually working on. Once BD is complete we look at the FP just to make sure everything’s visible and is in a good shape. Often we find that many controls and indicators are missing from the view and are badly organized. It is painful to search for controls and move them into view. Instead an FP cleanup could put things into the visible space and organize them in a simple way (controls to the left, indicators to the right, similar controls and indicators on the same level, error cluster in the bottom etc). For most cases this might be sufficient. If not it could be used as a starting point to organize your FP. Also at the same time we could automatically connect these items to the connector pane as well. If you already have organized some items on your FP and you don’t want that to be disturbed, you could select such objects and exclude it from your FP clean up.
Example->
Let’s say you are working on a block diagram creating controls and copying some from other VIs.

Now you look at the front panel and see all the controls and indicators scattered.

Also many of them are not even visible in the FP area.

Simple FP clean up with connector pane connection will put it into this state.

Note the connector pane as well. The user can either use the VI in its current state or use it as a starting point to organize his FP.

LabVIEW Idea Exchange

Path Constants Relative to the Current VI's Directory Path

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

Option to open VIs or projects for viewing only ("locked" or "read-only")

Cleanup diagram - Improvements required

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

Disable the context help in executables

Option to Limit the Number of Characters in a String Control

String case structures should default to being case insensitive

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

XNET database editor show meaning of values

Relinking to a subVI should retain the subVI node setup settings

Include composition and usage relationships (and maybe others) in class hierarchy window.

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

Set a default webservice for NI Web Server

Show splitter bars more clearly in edit mode

align the upper input of "swap values"

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

In Range and Coerce for Waveform

AppBuilder should tell how long it took to build.

Front Panel Cleanup and Automatic Connector Pane wiring