LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Duplicating graph scale programmatically

We can duplicate a graph scale by right click, but we cannot do it when the VI is running.
It's better that we can duplicate and delete a scale both manually and programmatically on running VI.

For programmatic approach, I suggest invoked method like this:

Download All

View All (3)

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!

Sometimes you have to read a lot of shared, local or global variables in sequential order. In this case, it can be a bit "boring" having to drag all the variables by hand. In addition, if you are reading shared variables, you also have to wire all the error cluster inputs and outputs. It could be useful to implement something similar to a property node or a Read/Write Control FPGA Node that you can resize and select which variable must be read or written in each position of the node as you can see in the following image:

View All (2)

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

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)

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)

Case Structure Navigation

Case structures should have an easy to use Navigation like multiple grouped windows have in Windows 7. If a window is grouped in Windows 7 you will get a nice window that allows you to view what is in each window and navigate to the one that you want.

This would be very beneficial in LabVIEW for case structures.

It would look like the attached:

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

Run-Time Menus with Icons / Glyphs

When was the last time NI updated the Run-Time Menu Editor?

Yes, it's been a looooong time 😉

I think this should be put on the road map as soon as possible.

The user should be able to define glyphs that are shown next to the menu items, just like in any modern UI library.

The RTM editor itself could use a complete rework, too. At the moment that's not what I'd call use-friendly (you can't even resize the window!).

This applies both to run-time menus of VIs as well as controls and menus that are called programmatically.

No, I don't attach an image here - just click into the menu bar of any remotely modern application on your computer to get an example of what I'm talking about 😉

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

From considering a number of other ideas (see below), I want to suggest that the Block Diagram is the only item initially created when defining a VI, and becomes the place where ALL VI functionality is defined. The BD is the place where dataflow is specified and the functionality of the VI is determined. So it makes sense that the con-pane should be linked to the BD rather than the FP -- it defines the data interface between calling VIs to this VI. Similarly the icon often provides a visual clue to the VI functionality, rather than its FP look. So both con-pane and icon are natural components of the BD window.

From the BD, it should then be possible to define one, or more, Front Panels which provide user interfaces to the data. These FPs may contain some or all of the variables in the con-pane (why ever show Error In/Out?), along with some or all of any other controls/indicators used in the block diagram. In fact, the Probe Window is already almost an additional FP - just allow several data indicators to be grouped on a single window, and you essentially have a Debug Panel. It would be great to be able to save the Probe window (or several of them) with a VI.

Yes, there will be problems, not least that I'm sure some existing code assumes that an FP (and only one) exists if a BD exists. And that every control/indicator must have a FP representation.

Here's a rough mockup (though the Probe points could be "virtual indicators" instead):

Other related ideas:

Be able to link to the connector pane in Block Diagram

Sub VI without Front Panel

Custom Probe Watch Window

We need to uncouple the "edit mode" FP size from the "run mode" FP size

and one trying to address the same concerns, but in a way I don't like:

Add Data layer for VIs...

View All (4)

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)

Service Packs

View All (1)

View All (3)

The VISA test panel is a very valuable tool for troubleshooting instrument connectivity issues.

This used to be included with the VISA runtime, or at least with any installer that also included the VISA runtime.

Now I have to separately download and install the FULL VISA just to get this valuable tool.

That makes installing a LabVIEW executable a multistep process as now I have to run two different installers.

NI-MAX and the VISA test panel should ALWAYS BE included in any installer that includes the VISA runtime.

LabVIEW Idea Exchange

Duplicating graph scale programmatically

Relinking to a subVI should retain the subVI node setup settings

Implement Variable Nodes similar to Property Nodes

Filter dependencies from "Find Items with No Callers"

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

Make it easier to show the radix when you change it.

All build-able targets should have versioning

Case Structure Navigation

Cleanup diagram - Improvements required

Run-Time Menus with Icons / Glyphs

Ability to Group Decorations on the Block Diagram

Match autoscaled grids in multi axis plots

The Block Diagram should be the central VI component (not the Front Panel)

Option to "Dock" the Iteration Terminal

A Caching Structure!

Service Packs

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

Automatically include the VISA test panel in installers that include the VISA runtime

increase the amount of recent files / recent project

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