06-28-2016 06:20 PM
I've got a fairly hefty typedeffed cluster whose values I'm interested in. It only has doubles and booleans in it, no arrays or further clusters. Is there a way to programmatically grab the values within the cluster and convert them to a 1D array of strings to be logged to a CSV? I can explore other logging methods if need be. I tried using VariantType.lvlib, and got this far:
But as it turns out, the value tags don't get passed in from the first Cluster Info vi.
VI attached for reference.
06-28-2016 06:48 PM
Try the MGI "Read Write Anything". You should be able download it from VIPM.
Cheers,
mcduff
06-28-2016 09:55 PM - edited 06-28-2016 09:56 PM
Thanks, I'll take a look at it. In the meantime, I ended up replacing that "Cluster Info" VI with a "Cluster to VData Array" from the OpenG Variant palette which gave the desired behavior.
06-29-2016 04:20 AM
A little-known feature of the Variant-to-Data node is that it can convert a cluster to an array of variants. This is faster than the OpenG function.
-- James
PS Doesn't work in the other way sadly: link to idea.
06-29-2016 06:44 AM
If the type of file .csv is not mandate then you can log the file in Binary Format, where you can save cluster data without any conversion and read back again
06-29-2016 06:47 AM
06-29-2016 06:56 AM
Why are you not just using the existing OpenG Config or MGI liraries that write in INI format?
06-29-2016 06:57 AM
06-29-2016 09:01 AM
Your over-riding requirement appears to be that the file be human-readable. You are "settling" for a string representation, which is fine for a Boolean, but perhap less satisfactory for Dbl data (I forget how many digits of precision -- around 15? -- are carried in the Dbl format). Depending on how you format the representation of the Dbl, you'll get an "N-digit" approximation of the value (which, admittedly, is a 52-bit "approximation" to a real number) or a hard-to-read string of (possibly unnecessary) digits.
There is a way to "have your cake" (Human-readable) and "eat it, too" (retain native representation) -- instead of using LabVIEW's "Spreadsheet" File I/O functions (which write String representations/approximations of your data), you could, instead, save the data in an Excel WorkSheet. An Excel cell can "adapt" to the type of data stored in it -- if it is a Dbl, it can be held in "human-readable" format (with whatever display precision you desire), yet retain all of the bits-of-precision "under the hood".
Your task is a little more complicated by the (apparent) need to accept either Boolean or Dbl, but with the type not known, apparently, until run-time (which appears to be why you went through all of the shenanigans with Variants). Something you might consider, if this situation should happen again, is to write a Polymorphic "Store" function that can handle both a Boolean and a Dbl input (look up Polymorphic VIs in LabVIEW Help).
You can use the LabVIEW Report Generation Toolkit (if you have it) to create true Excel Worksheets. You can use the Excel Easy Table VI to handle the placement of a "table" (a 2D array of Text or Dbl) into Excel. Right away, however, we run into two (minor) problems -- Easy Table, though it is polymorphic, only accepts Text or Dbl data, so we'd have to change the Boolean to a TRUE/FALSE text string. Second, what do you do if you need to save single values (as you may not know whether you are saving a Boolean or a Dbl)? Simply -- Build Array twice will turn a scalar -> 1D array -> 2D array (albeit a 1x1 array). The final question is how do you control whether you are writing a row or a column of data? Use the Start input and two "Next Cell" outputs (and Shift Registers) to either make "next cells" line up "top-right" (in a row) or "bottom-left" (in a column).
This may be much too much effort, gross overkill, but since you "love math" (as do I), seem to be "getting into" LabVIEW (oop, I didn't mean to make a pun), and seem interested in some of the nooks and crannies, I thought I'd comment.
Bob Schor
06-29-2016 09:28 AM