Booleans in TDMS files

[CoastalMaineBird]

LV 2013, DIADEM 2012,2014, Win7

Not sure if this is a LabVIEW problem or not, but I'd like to find a LV workaround.

My app saves properties in the root level of TDMS files, for compatibility with data files, also TDMS.

I have a VI which will take a reference to any control (any that we use anyway), and store its value into TDMS properties. 

For most types, the code to WRITE it is very simple:

For other types, it's a tad more complicated, but not much.

When reading, it's equally simple for most types:

the properties are all VARIANTS - I simply feed the variant to the VALUE property of the generic control, and it's all good.  Again, some other types (clusters, arrays) are a tad more complicated, but that's not relevant here.

This all works perfectly - I can pass in a reference to a cluster of arbitrary complexity, and it gets written to the file just fine, and it will read back just fine.  The file is readable by DIAdem, which is a requirement. My code even handles arrays and generates names for each item in the control

EXCEPT

My problem comes with a BOOLEAN value. A simple, binary, Boolean control.

Could be a switch or slideswitch or rocker, or LED - doesn't matter. Just like the stinkin' "C" language, nobody agrees on how to handle it.

When I write the file from my LabVIEW app, here is what the property looks like:

It shows up as a BOOLEAN. That's right, with a TRUE or FALSE value.

Great.

Again, if I read this file right now with my LabVIEW tools, it's all good.

But DIAdem insists on showing it as a 1 or 0, not TRUE or FALSE:

That's STILL OK, because the users can understand it.

The problem is if they EDIT the file, in ANY way, then look what happens to the Boolean when LabVIEW reads it back:

Yes, the edit added some new properties, that's OK.

But it changed the boolean into a U8 !

And, of course, feeding a U8 variant into a Boolean control results in a false always (and an error, I suppose, but I'm not checking.

It's a freakin' BOOLEAN value - it's not that complicated !

So, what do I need to do?

I can have a special case for boolean, I guess I have to coerce the variant into an integer and then check for 0 or not? 

Any better ideas?

[Hooovahh]

So I don't know if this is related or not, but you know that a boolean is stored as a U8 in both the file, and in memory in LabVIEW.  Something about not being able to allocate a bit of memory from the OS.  So when you log to a binary file, or TDMS and you log a single boolean it will take up 8 bits of storage, not 1.

[CoastalMaineBird]

---

@Hooovahh wrote:

So I don't know if this is related or not, but you know that a boolean is stored as a U8 in both the file, and in memory in LabVIEW.  Something about not being able to allocate a bit of memory from the OS.  So when you log to a binary file, or TDMS and you log a single boolean it will take up 8 bits of storage, not 1.

---

My complaint is NOT that it takes up 8 bits.

My complaint is that it changes the DATA TYPE of the variant stored in the file.

If I read it BEFORE editing, the variant's data type is boolean,

If I read it AFTER editing, the variant's data type is U8.

And you don't have to edit the boolean itself, you don't have to actually change anything - just SAVing from DIAdem will change the data type.

I suspect that DIAdem is reading it wrong, since it displays as 1/0 in DIAdem, instead of T/F or True/False or something sensible.

But in any case, it saves it out again as U8.

[WestOfEden]

Hey there,

Apparently this is the expected behavior of DIAdem. As it does not accept boolean types, it coerces them to integers. Then when it saves, it saves them back as integers since it doesn't have a boolean type. 

[whitenoiz]

If you call DIAdem garbling my Boolean attributes "expected behavior", then I guess, let's keep it that way...