LabVIEW Idea Exchange

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

The LabVIEW compiler currently appears to use one core of a multi-core processor.  It would be nice if it fully utilized multiple cores to speed building of large projects.

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

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).
1. One where a value change triggers a recalcuation of the containing code
2. 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". 

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

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