simultaneous reading and writing TDMS files

[lmd2]

A client had a program written in 8.6; the programmer is no longer available and I am looking to debug some intermittent issues.

N-channels of data are acquired and streamed to a TDMS file. The operator can select a channel to view live data, but the display is a scope chart displaying 15 seconds worth of data, and when switching channels the program 'backfills' the display with the past 15 seconds worth of data from the new channel (the backfill data being retrieved from the TDMS file).

What I notice here, aside from the sloppy use of the error cluster, is that two references are opened to the file - one for writing data and one for retrieving data. Is this a good practice? is it necessary or can one reference support both reading and writing? Is this a possible source of problems?

 

thanx

lmd2 

[Pcorcs]

LMd2,

TDMS file by design allow concurrent file access. You may verify that you have correctly configured this access scheme via an example shipped with LabVIEW. Please Select Help >> Find Examples >> Search 'TDMS' >> TDMS-Concurrent Access. In the example 2 references are used, one for the file write, the other for the read. The structure closely paralles a producer consumer structure.

Thanks,

PCorcs

[Ben]

---

lmd2 wrote:

...

is that two references are opened to the file - one for writing data and one for retrieving data. Is this a good practice? is it necessary or can one reference support both reading and writing? Is this a possible source of problems?

 

thanx

lmd2 

---

I had trouble with that approach. What I saw was the Reader reference only could see that data that had been writen to file PRIOR to the ref being open. Anything added using the other ref simply did not show up. I tried flushing to get it to show but no joy. In my case I found this by accident because I was dropping the first ref and my code was automatically opening a new ref. The data was still there, the new just could not see it.

I hope that helps,

Ben

[Herbert Engels · Accepted solution]

You can do the same thing with a single file reference.

The issue of not being able to see data that has been written after the reading reference was opened is known for having refnums open in two different processes, but not within the same executable or VI.

Herbert

Message Edited by Herbert Engels on 02-19-2010 10:37 AM

[lmd2]

had I written it from scratch I would have used one open reference, didn't know if I was missing something

didn't know if this was a better approach, but leaner would seem better  

thanks for the support

-lmd2 

[Ben]

Thank you Herbert!

There is no better answer than hearing from the author himself.

Ben

[blawson]

I had a read/write implementation where I could only read data written to the tdms prior to the most recent flush. I believe I was keeping the same reference alive for subsequent reads.  constantly flushing was inflating the size of the file, so I wanted to defrag, but I couldn't defrag succesfully unless I closed all of the references (irrespective of read/write access) and *then* called the defrag.

edit:

A-HA, thanks herbert!! 

Message Edited by blawson on 02-19-2010 12:52 PM