Working with "true anything" data

[crandiba]

Hi guys,

Sorry to bother you but I have an issue I want to get some feedback on; 

While doing the logger for my application, I wanted to be able to send in all types of data from all over to it, then just save it. Of course we could just do it with a normal variant, but that would mean making a bunch of cases for when we want to recuperate the original data - not the most elegant approach, even more so if you wanted to make the Logger a universal VI, to be used in any application..

I hope I haven't lost you thus far; 😄

So I was thinking about the following: instead of just converting it to a variant, we also take a pointer (Data Value Reference -DVR, I guess) and build a cluster/array of the 2 things. When we want to reconstruct the data, we would use the DVR that was passed along and voila.

"Works" in theory, but my problem is the Void Wire, that makes this impossible to be called. Well, I'm sending you the VI attached so I'm sure you'll understand it immediately when you have a look. 

If I wasn't clear enough please let me know, and I apologize in advance for my labview "noobness" since I only really got into it in the last couple of months but it would be awesome if this could work. Next I'm looking into putting everything into a single variant and scanning the variant for the Data Value Reference field, jsut to let you know.

Thanks again and sorry for the long message guys!

Have a Great Day Everyone!

Cris

[GerdW]

Hi crandiba,

"anything" is an empty cluster container. What do you expect to happen with it?

It's just an undefined datatype to LabVIEW!

[crandiba]

Hi there!

Thanks for the quick answer;

Well, I was hoping to use it as an input of the VI; that way, if we just separate the two parts of the VI I attached we could end up sending any type of data through a variant "pipe" and retrieve it on the other side without knowing the original type of the data to beguin with.

I know that for labview it is an undefined data type, so I guess what I was hoping is that we could "specify"or declare if you will the type of data at runtime - whatever comes through, we would just need the *type* to make it work.

Btw, I understand you can just pass on the reference to it and using that, but I was hoping there was a way of doing it this way.

Sorry if I am not very clear with this and I really appreciate your consideration and input! Thanks again 😄

[Hooovahh]

Someone correct me if I'm wrong.  But LabVIEW is a strickly typed programming language.  It must have all data type declaired at run time.  The loop hole (but not really) is variants.  A Variant terminal on a front panel can accept any data type and then you can convert it to whatever you want.  But even here every thing is defined at run time.  The data type into the sub VI is a variant (so defined) and then when you convert it back into something usable, that type must be known (so defined) for the conversion to happen.  There isn't a null data type.

So the closest you can get is to have a variant as the terminal then convert to what you want.  But if you try to convert it to something that the input wasn't provided by the calling VI you will generate an error.  If you provided an array of doubles and want to use the Variant to Data to convert to a string, it will generate an error at run time.

Currently the more correct way to do this is with polymorphic VIs.  A polymorphic VI is just a collection of VIs, and at development time one is selected to be used usually based on the type of data provided.  So instead of haveing a Variant VI that could have errors if you provide the wrong data, you have 10 VIs each with different data types for the common use cases.  This won't cover all data types of course but it won't have run time errors if it is used incorrectly either.

[rolfk]

---

@crandiba wrote:

Hi there!

Thanks for the quick answer;

Well, I was hoping to use it as an input of the VI; that way, if we just separate the two parts of the VI I attached we could end up sending any type of data through a variant "pipe" and retrieve it on the other side without knowing the original type of the data to beguin with.

I know that for labview it is an undefined data type, so I guess what I was hoping is that we could "specify"or declare if you will the type of data at runtime - whatever comes through, we would just need the *type* to make it work.

Btw, I understand you can just pass on the reference to it and using that, but I was hoping there was a way of doing it this way.

Sorry if I am not very clear with this and I really appreciate your consideration and input! Thanks again 😄

---

That is analogous to taking your car, squishing it to a a small cube of trash and then hoping to find a way to magically inflate it back to its original form. It just doesn't work!

[crandiba]

Hi again,

Yeah, After a day of trying out some stuff I do believe I am coming into that very same conclusion.. Along with what Hooovahh mentioned, I don't think there will be a way since the pointer needs to have a "type"declared as well - its a catch 22 of the same problem I guess.. If only we had a way of converting the reference to a data type we previously known (say, string) and back into the original reference type, we could make it work..

Anyhow, I appreciate your input guys, and thank you for all your consideration! 😄 

[Hooovahh]

---

@crandiba wrote:

Hi again,

If only we had a way of converting the reference to a data type we previously known (say, string) and back into the original reference type, we could make it work.. 

---

You can with Up/Down Cast reference.  But again what are you casting it to?  It needs to be known at run-time, and compatible.  You can't cast a string reference to a generic "Control" reference, and then to a numeric reference.  You will get an error.  But you can go from String -> "Control" -> String, or even ComboBox -> "Control -> String will work because ComboBox is a type of string.

[crandiba]

You're right, sorry, it seems I'm only going around in circles: we would then have the same problems in needing to know the type in advance and would void the whole purpose..

Sorry guys, and big thanks, as a newcomer I really appreciate your feedback!

[Hooovahh]

---

@crandiba wrote:

Sorry guys, and big thanks, as a newcomer I really appreciate your feedback!

---

No problem.  I will bet that in 5 years when you are an expert you will say to your self.

"You know what would be great is if I made an architecture that accepted any data type and just worked with it, and converted it to what I needed."

You will then spend time going in the same circles we have discussed here.  It can work in limited situations, but will struggle with some edge cases.

The OpenG write variant to INI is a neat one that works in a limited scope.  It will take any data you have and write it to disk.  Then it reads from disk back.  There are many problems with complicated and large data types taking a long time to read/write, and doubles will have precision cut off at some point, the file size balloons because it flattens to a human read able string, and a few other draw backs.  But whenever you want to see how it is done mostly right take a look at that code.