LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

When I build a web service in LabVIEW, there is no version number updated for each build. If I then install that web service on my target, I have no way of determining what build has been installed.

I have solved this by creating some scripting VIs that update a VI control's default value when the build is run. This VI is available via my web service so I can ask it what version it is.

I think everything that can be built from the project should have a version attached to it and that version should be accessble and reportable. Also, it should be possible to auto-increment it.

View All (4)

View All (3)

"Find Items with No Callers" could be a useful function on the project, but currently most items it reports are in Dependencies. Why is an item even under Dependencies if there is no caller? It seems if I call one function from an .lvlib the whole library is in dependencies, and all other functions have no callers. This floods my "Find Items with No Callers" window with useless entries.

Suggestion: add option to hide items from dependencies in the "Find Items with No Callers" window (or even hide them by default).

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)

View All (4)

Bookmark manager is extremely useful for navigating large code bases. Every feature I have in flight, I've got marks for all my expected or in-progress work. Sometimes I'm using it to navigate through related chunks of code. So I'm constantly referencing it. But it gets buried behind windows, just like the equally useful Error List Window. I'm constantly reopening both, but the Error List Window has a quick hotkey to bring it to the front (ctrl+L). I'm finding more and more that I want Bookmark Manager to have a hotkey too.

I've edited my personal menus to have "ctrl+," as the shortcut key, but I wish I could grab ctrl+k as a better mnemonic. Ctrl+k is currently paired with ctrl+j for bring to front and back... and those are keys that cannot be reassigned by users because they aren't main menu items. Personally, I'd place higher priority on accessing Bookmark Manager than reordering zplane, but I understand I might not be in the majority there.

Anyway, the idea is for some standard key to be assigned to the View>>Bookmark Manager menu item.

View All (1)

Anonymous Method Structure

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

A Caching Structure!

I often have a situation where certain code parts don't really need to be recalcuated, because their inputs have not changed from an earlier encounter.

For example if a function is the sum of two different complicated and slow calculations where each of the two depend on a different subset of parameters, often only one needs to be recalculated, while the other intermediary result could be grabbed from a cached value. (This occurs for example during the calcuation of partial derivatives).

In some cases, the compiler could probably recognize these situations, but I think we should have a special structure to allow caching of intermediary results.

I typically use a case structure and two feedback nodes as shown in the example on the left. If the value is different, the code in the TRUE case is executed, else the value stored in the SR is returned immediately. (If the code depends on several values, I bundle them all before the comparison operation)

I propose an simple Caching Structure as show on the right that retains that same functionality with less baggage.

Details: The containing code is calculated at first run and stored in the output tunnel. In later calls, it is either (A) recalculated, or (B) the previously stored value returned at the output tunnels. Recalculation only occurs under some conditions (.i.e. usually when actually needed)

The structure has the following features:

Two possible types of input tunnels (the functionality is indicated by a different look).

One where a value change triggers a recalcuation of the containing code
One where a value change does not trigger a recalculation of the containing code

A special boolean terminal to force a recalculation unconditionally
output tunnels that retain data between calls

There can be an unlimited number of input and output tunnels of any type described above. A recalculation of the inner code occurs if any of the triggering tunnels have a changed value.

We can think of it similar to "short-term folding".

View All (2)

Whenever you use multiple scales in a graph and use autoscale the grids usually don't match. See left graph.

One simple solution is to show only one grid, however the ticks on the other scale(s) wouldn't match the grid. 😞

Wouldn't it be nice to have a autoscale with matched grids in multi axiy plots? At least as an option?

Nice autoscaling is tricky 😉 and marking the ticks is tricky (scale size/font size/...), so my simple approach only works with larger scales (and only uses the major grid) ...

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!

Multi-Core LabVIEW Compiles

View All (2)

System Containers

As already mentioned here long ago, there is a need for system containers.

Most of my front panel uses system controls/indicators and I often use arrays and clusters. The currently available containers (modern, classic) simply don't match the overall system style.

The system palette needs a "System Array, Matrix & Cluster" sub palette.

A quote from my old comment says it all:

For example, there is no "system" array container (with a correctly colored frame and a system spin control as index control) or "system" cluster container (could look similar to the system radio button control).

View All (3)

Service Packs

View All (1)

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)

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...

LabVIEW Idea Exchange

All build-able targets should have versioning

Option to "Dock" the Iteration Terminal

Provide a tooltip for Recent Project entries to see project path

Filter dependencies from "Find Items with No Callers"

Enable Undo/redo (CTRL Z/CTRL Shift Z) in the VI properties >> documentation window

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

XNET database editor show meaning of values

Give Bookmark Manager a hotkey to open it (ctrl+k would be nice)

Anonymous Method Structure

Cleanup diagram - Improvements required

A Caching Structure!

Match autoscaled grids in multi axis plots

Relinking to a subVI should retain the subVI node setup settings

Multi-Core LabVIEW Compiles

System Containers

Service Packs

Allow labeling to the probe

Allow Conditional Terminal to be High or Low

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

Disable the context help in executables