TDMS Get Property does not like CXT type has an input to "data type"

[PJM_labview]

There is a bug in the TDMS Get Property when type input is a complex number (CXT Type). Trying to connect the CXT data type to the data type input and a string to the property name input keep braking either one of the wire.

http://forums.lavag.org/index.php?act=attach&type=post&id=5563

Note: It is sometime possible to get it connected through some undo combination but the the type does not propagate to the property value output in any situation.

http://forums.lavag.org/index.php?act=attach&type=post&id=5564

PJM

[Herbert]

This is another occurrence of data types that are available in LabVIEW, but not in other TDMS clients like DIAdem or CVI. We are gradually implementing these data types, but for each of them, we have to find ways of making it work for the rest of our platform, which is sometimes not as easy as it sounds. I cannot currently give you a timeframe for when complex numbers will be supported.

The bug here is that there seems to be a way of wiring up a complex number and undoing stuff so the wire isn't broken.

Herbert

[PJM_labview]

Thanks for the feedback.

If there are unsupported data type, may be the help for "TDMS Get Property" should be updated to reflect that.

Is there any other unsupported types?

PJM

[Herbert]

QUOTE(PJM_labview @ Apr 20 2007, 10:51 AM)

If there are unsupported data type, may be the help for "TDMS Get Property" should be updated to reflect that.

Is there any other unsupported types?

PJM

I agree. The help for "Set Properties" actually lists the allowed data types, unfortunately the list is wrong. I've filed documentation CARs accordingly. The following data types are allowed as TDMS properties:

• U8, U16, U32, U64
  
• I8, I16, I32, I64
  
• SGL, DBL, EXT
  
• String (alphanumeric, cannot contain null terminator(s))
  
• Timestamp
  
• Boolean (supported, but there's a bug with booleans in "Get Properties")
  
• Variants that contain any of the above types
  

Any other data type should either break the wire or return a runtime error.

Herbert

[bbean]

QUOTE(Herbert @ Apr 20 2007, 02:43 PM)

I agree. The help for "Set Properties" actually lists the allowed data types, unfortunately the list is wrong. I've filed documentation CARs accordingly. The following data types are allowed as TDMS properties:

• U8, U16, U32, U64
  
• I8, I16, I32, I64
  
• SGL, DBL, EXT
  
• String (alphanumeric, cannot contain null terminator(s))
  
• Timestamp
  
• Boolean (supported, but there's a bug with booleans in "Get Properties")
  
• Variants that contain any of the above types
  

Any other data type should either break the wire or return a runtime error.

Herbert

I'm really excited about using these TDMS files and an OpenG variant config for TDMS. I started to implement the stuff from PJM :thumbup: . Thanks for all you help.

When I added a numeric to the clusters I found it was not reading back properly.

http://forums.lavag.org/index.php?act=attach&type=post&id=5604

I believe this results from the fact that the TDMS Write Key write the value as a string:

http://forums.lavag.org/index.php?act=attach&type=post&id=5606

and try to read it back in using its native datatype.

http://forums.lavag.org/index.php?act=attach&type=post&id=5607

Before I start working on improvements this brings up a few questions.

1) Should we formalize the development in OpenG and start tracking the version changes.

2) Should we store data in the TDMS file in its native datatype (dbl, u32, etc) when possible for compatibility with other software Diadem, etc or should we just store it as a string and convert it back to the data type when we do the read.

[Grampa_of_Oliva_n_Eden]

QUOTE(bbean @ Apr 23 2007, 09:23 AM)

I'm really excited about using these TDMS files and an OpenG variant config for TDMS. I started to implement the stuff from PJM :thumbup: . Thanks for all you help.

When I added a numeric to the clusters I found it was not reading back properly.

http://forums.lavag.org/index.php?act=attach&type=post&id=5604

I believe this results from the fact that the TDMS Write Key write the value as a string:

http://forums.lavag.org/index.php?act=attach&type=post&id=5606

and try to read it back in using its native datatype.

http://forums.lavag.org/index.php?act=attach&type=post&id=5607

Before I start working on improvements this brings up a few questions.

1) Should we formalize the development in OpenG and start tracking the version changes.

2) Should we store data in the TDMS file in its native datatype (dbl, u32, etc) when possible for compatibility with other software Diadem, etc or should we just store it as a string and convert it back to the data type when we do the read.

If the data is stored as "native datatype (dbl, u32, etc) " DIAdem can do its magic without any help, correct?

Just questioning out loud,

Ben

[bbean]

QUOTE(Ben @ Apr 23 2007, 09:27 AM)

If the data is stored as "native datatype (dbl, u32, etc) " DIAdem can do its magic without any help, correct?

Just questioning out loud,

Ben

Probably. But I haven't worked with Diadem at all.

Attached is a modification to the library that contains a quick fix to the numeric problem. Keep in mind it was done quickly to check the option of storing the data natively. So there may still be bugs.

As an extra bonus it also has a new example that saves clusters to specific group/channel. This is nice because you can place your cluster properties at any level in the TDMS format. Let me know what you guys think.

Brian

This post should probably be moved / combined with http://forums.lavag.org/index.php?showtopic=7486&st=0&p=28510entry28510' target="_blank">TDMS for big config clusters -- is there a better way?

[PJM_labview]

QUOTE(bbean @ Apr 23 2007, 07:14 AM)

Probably. But I haven't worked with Diadem at all.

Attached is a modification to the library that contains a quick fix to the numeric problem. Keep in mind it was done quickly to check the option of storing the data natively. So there may still be bugs.

As an extra bonus it also has a new example that saves clusters to specific group/channel. This is nice because you can place your cluster properties at any level in the TDMS format. Let me know what you guys think.

Brian

This post should probably be moved / combined with TDMS for big config clusters -- is there a better way?

I think we should mouve back the discussion to the original thread, since this one is about a bug report.

About the numeric issue, good catch. I will work more on this today.

PJM