Jump to content

TDMS for big config clusters -- is there a better way?


Recommended Posts

Back again.

I found that a little tweak down in the low level Write_Key and Read_Key functions allowed me to properly handle a few DAQmx Global Channels I had embedded in my config clusters. (I had previously been willing to live with losing the info but played around with trying to reconstruct it.)

In short: the DAQmx Global Channel comes through as a datatype of "Refnum", value=70 (hex). I personally don't have any other cluster elements treated as Refnums, and I tended to doubt many Refnum thingies have any static meaning in a datafile anyway -- most any Refnum I think of is generated dynamically with an "Open" or "Create" type of call.

Prior behavior: DAQmx Global Channels were identified as "Refnums" and were caught in the "Default" case where they were written as a flattened binary string. The subsequent Read failed to reconstruct the channel name from the flattened binary string.

My change: both the Write_Key and Read_Key functions supported a case for datatypes identified as "String" or "DAQ". I'm entirely guessing, but perhaps the "DAQ" datatype is some other type of device or virtual channel type, perhaps from traditional NI-DAQ rather than DAQmx? In any event, I included "Refnum" in that list of types to handle. Here the DAQmx Global channel is written as a standard string. A similar change in the Read_Key vi properly reconstructs the channel name.

I'm attaching the modified files here, but am not at all qualified to judge whether this change is likely to help or hurt other users. It feels risky, though I can't think of other cases where it'd be useful to reconstruct the value of a Refnums in a file. Maybe there's a better way to more conclusively identify the sub-type of the Refnum so it can be treated as a special case?

-Kevin P.

Link to comment

You should be safe there. DAQmx refnums are indeed special in that they can be casted into strings. That applies to a variety of them, including channels, tasks, tags etc. I'm not sure it applies to all of them. LabVIEW automatically coerces these refnums to strings if they are wired to a terminal that expects a string.

There have been some issues in the past if you use DAQmx refnums as attributes of variants or waveforms, where the variant/waveform goes into a LabVIEW function that tries to process the attributes. Doesn't look like you're going to have that use case though.

Herbert

Link to comment
  • 3 weeks later...

I have use this librairie it is very usefull!!

Thanks!

However, I have experience something strange.

I have tried to write two clusters that are exactly the same format but with differents names.Writing the TDMS file does not give me an error but I do not have the information in the tdms file. Only one of the two clusters is written in the tDMS file. If I remove one element from one of the two clusters then the 2 cluster are written normally in the TDMS file!!!!!!

Did someone tried it? Is there a solution? I am doing something wrong?

Thanks for any help!!

CTR

I made a reader as well based again on the OpenG Variant Configuration Tools.

PJM

Moderator Note: The attachment has been fixed and is located here.

Edited by Michael Aivaliotis
Point to new attachment location
Link to comment

Bug fix with LabVIEW 8.2.1

The probleme was occuring with labVIEW 8.20. I have installed the new version of LabVIEW 8.2.1 and the problem was resolved. I have tried on differents machines with the two versions of LabVIEW.

Hope It can help other person!!

CTR

Link to comment
  • 1 year later...
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.