Writing data to a text file from a cluster.

[Blaze888]

Hello everyone, i have attached the following block that features a cluster consisting of different data types, numeric, string boolen and 1D array. Then i convert the data to a variant data and i create variant array. However when i try to save the data to a text file i get a result that isnt fully readable. I expect a result such as 

Age 12.00

First name  "Ivan"

Second Name "Petrov"

Boolean  TRUE

Array1  1 2 3 2 3 

Array2  "aasd" "sdsd" "sdfdgf" "dfdf"

[GerdW]

Hi Blaze,

why do you expect such a result?

When you convert your cluster into a variant it not just takes the included data, but also all "additional" information (like cluster element labels and datatypes) - and it will also write all this information into the file!

When you don't want all that additional information you need to convert your cluster content into text "manually" - using UnbundleByName followed by FormatIntoString might lead to one solution…

[CanadaGuy]

The closest thing will probably be Flatten to JSON or Flatten to XML to get something readable. As GerdW said, there is other meta data that is contained within a cluster that needs to be considered as well. JSON or XML will handle that for you. You can also read that text file back in.

[Rombusz · Accepted solution]

Dear Blaze!

I attached a sample code that produce a similiar result you expect. If you want to use it with variants, you simply have to call the Variant to Data function on the corresponding variant and use the reference of the result cluster. In this case you must wire a cluster type constant which has the same controls as the variant has inside, to the Variant to Data function.

However, as the others pointed out before me. It is easier if you use flatten to string or flatten to xml functions.

Best Regards,

Ferenc Zádori

[Blaze888]

Thank you for the time and effort and put in to help me.I tried different functions and i found out flatten to JSON worked the best out for me. 

Best Regards,

Zlatev

[rowdyr]

Hi All,

The native LabVIEW Flatten to JSON will not accept a variant input. So if you don't know the datatype before runtime, this VI will not work for you. JKI have a JSON toolkit that has a similar function that is much more flexible that the native LabVIEW one and will accept variants.

But here is another solution that might suit some people (see attached VI). It will convert a variant of almost anything to a single line readable string much like a JSON string. It was intended for datalogging where the data just needed to be human readable. And because it's just a single VI, it doesn't have all the dependencies of the JKI/OpenG toolkits. It could be adapted to be multiline if required.

I should also mention that OpenG has a library called Variant Configuration File that will save and recall clusters of any data to readable INI files. This is a great tool too.

[GerdW]

Hi rowdyr,

---

@rowdyr wrote:

But here is another solution that might suit some people (see attached VI). It will convert a variant of almost anything to a single line readable string much like a JSON string. It was intended for datalogging where the data just needed to be human readable. And because it's just a single VI, it doesn't have all the dependencies of the JKI/OpenG toolkits. It could be adapted to be multiline if required.

---

Nice work, but two comments:

• the VI has a dependency to _JKI.lib\Serialization\JSON\Library\Waveform Cluster.ctl
• I recommend to format timestamps using ISO8601 instead of relying on OS-specific settings!

[rowdyr]

Hi GerdW,

Good catch with finding that dependency. I've removed it and included an ISO8601 timestamp option. Updated VI is below.

Regards

[GerdW]

Hi rowdyr,

---

@rowdyr wrote:

Good catch with finding that dependency.

---

That's an easy one when you don't have that JKI package installed…

---

@rowdyr wrote:

I've … included an ISO8601 timestamp option.

---

Only partly. The timestamp misses a timezone indication, which is crucial (IMHO).

What happens when you transfer data files from Asia to Europe or Americas?

At which time a measurement took place when all you know is "08:00:00.000"?

(You forgot the timestamp in waveforms…)

Yes, I'm picky about tis one. But that is from own experience and lots of discussions…