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

[Kevin P]

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.

[Herbert]

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

[PJM_labview]

Kevin,

One common way to handle these refnums (Daq Task, VISA ...) is to coerce them to string in your data structure prior to attemp to write them to disk. The read sring automatically coerce back to the refnum when read back. See image below.

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

PJM

[CTR]

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 October 6, 2009 by Michael Aivaliotis
Point to new attachment location

[CTR]

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

[ritesh024]

Why can't i see Write TDMS Cluster_TDMS.vi in my OpenG package ??

I updated OpenG package around a month back.

is it a recent launch ??

Ritesh

[LAVA 1.0 Content]

QUOTE (Kevin P @ May 3 2007, 07:31 PM)

Back again.

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.

QUOTE (ritesh024 @ Apr 3 2009, 02:04 PM)

Why can't i see Write TDMS Cluster_TDMS.vi in my OpenG package ??

I updated OpenG package around a month back.

is it a recent launch ??

Ritesh

The VIs are not part of the OpenG package, Kevin has uploaded them to this thread, here.

Ton

[ritesh024]

I want to store "array of cluster" in TDMS file.

First i wired the "array of cluster" wire to the Write TDMS Cluster_TDMS.vi, and it gave some error. Then i created a cluster of array of cluster and wired it to the Vi and it hung my Vi.

How can i store array of cluster in tdms file ?

Ritesh

[PJM_labview]

Post what you have so we can give you better feedback.

PJM