New primitive to get the contained data type of a strictly-typed reference

[raphschru]

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

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:

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.

[Yamaeda]

Sounds like a new Data Type Parsing Variant-VI could solve this. Nice idea.

[raphschru]

@Yamaeda

Yeah but that has to be a primitive (yellow) node, I think there is no way a simple VI or even a VIM could achieve this. 

In the Data Type Parsing palette, there is already "Get Refnum Information.vi" that gives the inner strict type of a refnum as a variant (at runtime). What I want is the inner strict type through data type propagation (so at edit-time).

[avogadro5]

Not opposed to the idea, just pointing out that this one https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generalize-backwards-propagation-technology-Backwards... might also allow the user event application you're currently unable to do, because you could "backwards propagate" the type from a generate user event node.

[raphschru]

@avogadro5 Even with backwards propagation, we would not reach the complete functionality because the input terminal of "Generate User Event" is always named "event data", so we still miss the data name:

Note the "fake" case structure to avoid sending an actual event to the input user event.

This code would not compile as is due to the unwired "Always Copy" node, so more trickery is needed to get a functional code using backpropagation...

[avogadro5]

Would this trickery do it? Since you have the names you want on the input wire datatype. This is what I use to preserve stuff like cluster names.

[raphschru]

@avogadro5 you have a point for the data name.

There are even multiple techniques to keep the names:

Even with backwards propagation implemented, I would be curious to see how that would work exactly. It would require:

1. A forward propagation to "Generate User Event".

2. A backwards propagation from terminal "event data" of "Generate User Event" to some dummy node like "Variant to Data".

3. A forward propagation from the dummy node to "Create User Event".

I mean, even if backwards propagation is implemented, it would require multi-step forward/backwards propagation, which seems beyond the initial requirement of the idea.

[Jim_Kring]

I would imagine using a malleable VI, type structure, And clever use of case structures that do not execute code And contain appropriate type “unbundlers” Like the associated dequeue, Register for events plus event structure, Wait on notifier, Read datalog file, In place structure , etc. would make an extremely flexible VI That does what you were after. You are correct that having the correct name/label for the wire could be very tricky in most instances.

[raphschru]

@Jim_Kring This is what I had attempted here:

https://forums.ni.com/t5/LabVIEW/How-to-get-the-data-type-inside-a-User-Event/td-p/4449662

...but the general case for user events seems impossible (in case it contains a cluster with N elements).

I guess you could do a VIM that supports a maximum of, say 16 elements, but that would be clunky.

An XNode could achieve that easily, but then I cannot use it inside a malleable VI (because not inlinable), which was my initial need.