LabVIEW Idea Exchange

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

All service packs should be useable for the version you own, regardless of your SSP status. Currently, service packs are only good if you have a SSP active or had enough forethought to buy it in the middle of the year between versions.

I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".

I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:

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.

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

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 think LabVIEW should have something like the dialog VIs that acts as a popup where the vi displays a message to the user but doesn't hang up code and wait on the user to press a button.

An example case is a state machine that has error checking built in errors out.  Instead of creating a more complex error handling scheme to display the state machine errored out and heres why then shutdown the state machine, you could instead drop this async popup in the state with the message to display the error occurred then have the state machine shutdown like normal.  This way, the user knows "the state machine shutdown for X reason" while the state machine also goes into a safe state.  

I think the async popup is easier to trace since the error message is located in that section that detected the error vs having some sort of store an error string then in the shut down case read if there is an error and if so display the error once the station is already shutdown.  Additionally, you cold see where all asnyc message blocks are via dropping one in your code then right clicking and searching for all instances.  This could streamline the process to see where the fault occurred since the async message block would be in the location of the fault itself.

I have currently built something like this that is a reentrant VI whose input is a string and a secondary VI that launches the display message VI.  It's a bit of a work around, but I can display a message to the user while my code continues to do whatever it needs to.  

In a LabVIEW built executable the Context Help window can always be forced to appear with the CTRL+H shortcut. This isn't always desirable, and indeed I'd like to be able to prevent this. Can we have an option in the Application Builder to ignore this shortcut for executables?

It's not always desirable