LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get variable name and type dynamically

Sorry, you are right, I tried to keep the question in my first post direct, but an overall picture would be better.  Here is what my overall goal is:

I have my LabVIEW program controlling an experimental setup as well as logging data from it.  Right now I have about 15 variables I am recording, but wish to increase this to 30 in the near future, and probably many more in the not so distant future.  What my data file is is just a simple text file that is tab delimited so that I can read it easily in Excel.  I want a header to be produced that has the variable names, and then in subsequent rows, there are the values of each variable.  I record data about twice a second.

The reason I asked my questiona bout the cluster is that I pass my data around my main VI and to my sub VIs in a large cluster.  Since I want to have my data logging done in a sub VI, I pass all my variables to it in a cluster.  Before, I was manually writing out a header string to be written to a file, and then connecting all my variables to a "Format to String" VI with a very long format string.  I just saw this approach getting out of hand whenever I wanted to add or delete a variable to be recorded.  I looked at some of the built-in VIs for writing to a spreadsheet file, but they seem to require arrays of all the same data type, which isn't suitable for my application.

I am new to LabVIEW, so I really don't know the most efficient way of doing things, but your help really is appreciated and it helps me learn.  I welcome any suggestions for writing my data in a more efficient manner.  Also, if I still haven't made my overall goal clear, I can try clarifying it more.

-Ian
0 Kudos
Message 11 of 16
(1,899 Views)
OK, now I understand better. It seems you have two issues. The first is that the data you're trying to save isn't all the same data type. The second is that you want something that's not going to be difficult to update in the future should you add/delete data items. The variant route that you took is one way. Another way was your original method, but as you said, those format strings can get pretty cumbersome when long. You can mitigate this by creating a VI that generates the string for you based on your data cluster. Another method is to use the "Flatten to XML" function. This function will flatten anything to a nice XML string. In fact, for you, it generates what you need. You get the labels and the values already formatted. You basically just need to separate out the XML string to get your row of values. As for the header, you don't need to use variants as the detour. You can either use the same "Flatten to XML" method, or use the property nodes. I put together a simple example for you to take a look at. Whether it's faster for you than the variant route you'll need to see for yourself. Note that I made the cluster a typedef. I think you really need to do this for your application so that when you change the cluster you only change it one place.
0 Kudos
Message 12 of 16
(1,869 Views)
smercurio,

I like your idea of using the XML string to get out the value in a string format.  You could also use this to get the labels as well, which would be useful in my case, since I do not want to record values from all elements in my cluster, only selected ones.  This means reading the label from "all controls" wouldn't get me what I need.  I think that I will keep my implementation with variants, since I have that working just fine.  I do greatly appreciate you mentioning using a typedef though, as I didn't think of doing so before, and that'll help simplify updates greatly.  Thank you again for all your advice.

-Ian
0 Kudos
Message 13 of 16
(1,860 Views)


@smercurio_fc wrote:
Unfortunately Partha, that suggestion doesn't answer the question, since that provides flattened data, and Ian wants human-readable strings. Also, it employs the use of an unsupported "scripting" function, as evidenced by the red property node.

Hi smercurio, I dont understand your statement, it employs the use of an unsupported "scripting" function, as evidenced by the red property node.

Is it there inside the Vi I attached, or are you telling in general ?

I cant see these things in my VI. Smiley Indifferent

Please clarify me reg this. I m using LV 7.1.

- Partha ( CLD until Oct 2027 🙂 )
0 Kudos
Message 14 of 16
(1,854 Views)
There is a misunderstanding here. A red property node indicates a obsolete property/data type. You can see this when you open up a 7.x VI with panel items in 8.x (panels are kind a removed in 8).
The scripting color is somehting else.
Now I see why we have yellow and blue bars at the NI forums.

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 15 of 16
(1,842 Views)
Thanks for the correction, Ton.

My statement regarding the fact that it generates flattened data, which is not what the poster wanted, still stands, though.
0 Kudos
Message 16 of 16
(1,813 Views)