LabVIEW Idea Exchange

Currently each error in terminal contains the following description: "<B>error in</B> can accept error information wired from VIs previously called. Use this information to decide if any functionality should be bypassed in the event of errors from other VIs. Right-click the <B>error in</B> control on the front panel and select <B>Explain Error</B> or <B>Explain Warning</B> from the shortcut menu for more information about the error." This occupies 367 characters (bytes).

Currently each error out terminal contains the following description: "<B>error out</B> passes error or warning information out of a VI to be used by other VIs. Right-click the <B>error out</B> indicator on the front panel and select <B>Explain Error</B> or <B>Explain Warning</B> from the shortcut menu for more information about the error." This occupies 271 characters (bytes).

This applies to terminals of all styles: Classic, Modern, Silver, Fuse Design System.

This adds a total of 638 characters (0.62 KB) to each and every VI that uses a pair of error in/out terminals, which is probably a majority of VIs in LabVIEW.

The descriptions appear in the Context Help window and can be useful to beginners. But this benefit is not worth 638 bytes of space in so many VIs. The contents of the descriptions should be mentioned in training material such as LabVIEW Core 1 or the LabVIEW Help.

This proposal is to remove (clear) the error in and error out descriptions, such that VIs are "slimmer" and codebases are smaller.

Combined.png

Existing right click menu during wiring provides options to create terminals or wire branches.   Proposing a feature to add a cluster unbundle terminal when wiring clusters, that places and wires the terminal with the desired element reference.

Robzilla_0-1762307860683.png

The QuickDrop insert shortcut (Ctrl + I) is extremely useful already. The following enhancements would make it even more so.

Enhancement 1.png

Enhancement 2.png

Enhancement 3.png

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

 - Queue

 - Notifier

 - User event

 - DVR

 - Datalog file reference

 - Strictly-typed control refnum

 - Strictly-typed VI refnum

 - Shared variable

 - Network stream (reader/writer)

 - RT FIFO

 - FPGA IO / register / memory / FIFO / handshake

 - ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

raphschru_0-1755995515580.png

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

raphschru_1-1755996509116.png

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.