LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

NI packages installed though winget

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

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

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

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)

View All (4)

View All (3)

Disable the context help in executables

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.

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!

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.