Trouble with Concurrent Acess of TDMS file in LabVIEW 8.6

[FIC]

We developed code in Labview 8.5.  There are two appications, One writes data to the TDMS file and the other reads data from the same file on demand. This scheme originally did not work in 8.2 and we were told to migrate to 8.5. Subsequently after migration, it worked and worked well. There are 2 different references to the file in the two apps.

Now we have gone to 8.6. Overall the system works but time to tome it gives error 5 "File already Open". What I have noticed  is in my reading program we have a function theat reads the file size. The error happens during this. Once I eliminate this function it works.

Secondly, the error also happens when I am reading from the file and  if new data is being written to the file error 5 happens.

What has changed between the two versions and why? I was hesitant to upgrade  to 8.6 from 8.5. We need help or a definite workaround.

[FIC]

Here is the link to old thread with similar problem in 8.2 and advice from NI

http://forums.ni.com/ni/board/message?board.id=170&message.id=270806#M270806

[Herbert Engels]

Are we talking two different processes accessing the file at the same time? Do the applications open and close the file multiple times or do they hold on to the file reference once the file is open? Are both applications written in LabVIEW? Are you using DIAdem/DataFinder?

"TDMS Open" always opens files for reading and writing, unless "read-only" is wired to the "operation" input. Accessing a TDMS file for writing is possible only from one process at a time. Within that process, you can open several references for writing. With two processes, you would need some way of synchronizing the processes for them to share writing access.

Is there any way you can come up with a simple VI that reproduces the issue? I've run a few basic tests according to your problem description, all of which seem to work fine.

Thanks,

Herbert

[FIC]

To answer your questions

1. Yes we are talking of two different Processes, Separate EXE files.

2. The application that is writing, keeps its reference, it never closes it. The app that is reading opens the ref, reads the file and closes it. It is wired as "Read-only". The second app never needs to write to the TDMS file.

3. Both apps are written in LV.

4. No, I am not using Diadem/DataFinder

The problem happens before I try to read in the second App. It is giving me error when I try to get the file size. The code for "TDMS Open" is yet to be executed.

Once I eliminate the TDMA code to read file size (standard block from file palette). The app reads the data fine. Except while I am reading, if the first app tries to write data.

Hope that answers you Q. I will see if I can come up with a VI. It depends on my time usage, whether to come up with VI with no solution guaranteed or revert to 8.5 where the same code was working.

Thanks...

[Herbert Engels]

I attached a ZIP file that has writing and reading applications in it for each 8.5.1 and 8.6.1 (including built exes). This should mimic exactly what you do with TDMS in your application (including file size function). Both versions work fine on my computer. Can you run them on your machine and see if that works?

If it works, the root cause of the problem is likely not TDMS. We would need to look into other parts of your app / machine setup then. If it doesn't work, can you please post the version number of your TDMS.DLL? You can find the DLL in C:\Program Files\National Instruments\Shared\TDMS. The expected version for 8.6.1 is 1.2.936.563.

Thanks, 

Herbert

[aartjan]

In the mean time we have reached Labview 9.0. I also tried reading concurrently froma seperate exe back in 2007. I found then it wouldn't update it's channel length (see old posting). I was hoping by now this would work like a charm.

All I want is to read data from a tdms file while it's being written to by a measurement executable. the reader exe is merely a data player.

Unfortunately I can't get it to work at all anymore.

Opening the tdms in read-only will return a 2503 error (not a tdms file..)

Opening the index file invokes a memory full pop-up followed by a fatal crash (see attached images)

Peculiar thing I noticed: my simpel reader VI only reads some channel properties. It will open an index file just fine when the tdms is not being written to. But it creates a new index file!! As in testfile.tdms_index_index..

Is the possibility of concurrent access "deprecated" in tdms 2.0?

[FIC]

We had problems with TDMS 2.0 - Very similar to yours. All my compiled/built apps now needed a revisit (Error -2503) when we went to LV 2009. We had no time and resources to investigate this issue. We reverted back to LV 8.6.1 a and have never migrated to LV 2009.

We are happy the way it works today. I wish there was a better solution. There will be LV 2010 in a month. What then?

I am paying for subscription but not availing of all the improvements becasue of some issues like this.

Good Luck

[YongqingYe]

Hi Aartjan and FIC, 

We are very looking forward to investigating this problem. I tried Herbert's attached VI, run in LV 8.5 and LV 2009, but I didn't see any problem. In read data VI, it also get the file size. Would you please try Herbert's VIs and let us know is there any difference with your applications?

And, is that convenient for any of you to post a VI to reproduce this problem, it would be very helpful for us to investigate!

Thank you,

Yongqing Ye

NI R&D

[aartjan]

Sceptically I did try. And yes, it turns out it works! I do not understand why it doesn't in my application, but the proof is here.

I did remove the open in version constants so they both default in 2.0

Then I made the read VI more complex with a loop and a refresh button (open and close tdms outside the loop). Turns out that the constraint I mentioned in my old post (channel length doesn't update) is still in place. Ergo: you must close and open the file every time you want to see new data! Bummer, since that is actually misinformation. This issue had a CAR# before!

[YongqingYe]

Thank you for your quick reply. So, besides the channel length doesn't get updated, any other problems you find? Like what you described in above posts, e.g. data corruption?