LabVIEW Idea Exchange

Whilst pondering Chris Relf's presentation on LVOOP based error handling for NI Week, it occured to me that it would be really nice if it was possible to define LVOOP methods that would be called automatically when LabVIEW needed to convert a class to a different (eg built in) type.

For example, imagine I have a class for handling errors - the obvious thing to do is to wire that class wire into a case structure selector and provide cases for error/no error. Of course that won't work, but if I could define a method that takes my class in and outputs an error cluster and was somehow appropriately marked so that LV would automatically call it, then the case structure could automatically do 'the right thing'.

The inverse functions that build a class from another type would be a form of constructor for the class that might be useful - e.g. I have a class that represents a measurement, wiring a path control into the class terminal causes LabVIEW to run a method that I have defined and appropriately marked that loads the measurement from disc and initialises the class.

There are a few problems I can immediately see - if one defines two possible conversion methods (e.g. class to error cluster and class to enum) one needs to have a way of defining which one is used (right click on terminal of node would seem the most obvious to me) and you'd probably want a specially covered coercion node as well....

Motivation: in my recent project I have got a request from the end user that it would be nice to store configuration data in the same TDMS file where we store measurement results. Of course, we can create this feature programmatically, like we parse through the typdef cluster, using label names and different data types, we can create a kind of API for a TDMS Cluster read/write. However, it is difficult to make it generic, and this is an extra work anyway.

So it would be nice to save my complex Typdef cluster into TDMS, where I store measurement results in a user readable manner (via the Excel plugin) inside different groups and channels. The stored configuration cluster does NOT need to be user readable!

Since TDMS does not have this feature, as a dirty and simple workaround, I will always produce two files during measurement/data processing sequences: a TDMS, and an INI file (via the OpenG Write INI Cluster), then programmatically ZIP them into a single file for data backup (for future reference, it is safer this way).

Would not be nice if we could just write a Typdef cluster to and read from a TDMS file directly?

Like what we can do with the OpenG Read/Write INI Cluster VIs. I understand there is a strong reason why TDMS files limit the data types we can write to them, and it is not allowed to use undefined data sizes, like Variants, strings. Well, we can write strings to TDMS files, but there are some issues/difficulties with this approach if we want to go through a Typedef Cluster->String->TDMS file storing route. Hoovahh had a post about these challenges 2 years ago, where he mentioned he might make it into an Idea, but I could not find it in this forum board, so I make it an Idea: https://forums.ni.com/t5/LabVIEW/Read-Write-Variant-to-TDMS/m-p/3334203 

I imagine, NI could implement such feature into TDMS in a similar way, like there would be an "internal part" of the TDMS file where the Cluster is stored as a Variant in binary format. I do not know how the internal things work in a TDMS file, but I imagine such new feature implemented as an extra data type for the TDMS Set Properties would not hurt the speed performance of the Group/Channel level things...?

If you create a enum constant on the block diagram, then right click and show label and show digital display.

When you move the label around, it will snap to the corners (and middle of the sides) of the enum constant.  However, when you move the digital display around, it will NOT snap to the corners like the label will.

It would be nice if the digital display would also snap when you move it.