LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TDMS file issue

Hello,

I have an application down on an RT OS which logs data to a tdms file at 1Hz. When the reference to the tdms file is closed (using TDMS close), The data contained inside the file seems to go missing althought the increasing file size shows that there is data held in the file.
 
See attached files. The block diagram shows a tdms file read before the close; This contains several columns of data. There is also a tdms file read after the close, the output only shows one column of data. This is also the case when the tdms file is transfered up to the host PC and opened in excel, only one data point.
 
Any help would be greatly appreciated.
 
Rhys
0 Kudos
Message 1 of 6
(2,826 Views)

First suggestion: Replace the re-opening of the file with the "TDMS File Viewer" after the TDMS Close. It gives you a nice pop-up window that allows you to navigate your TDMS file. It's a nice way to get a grip on how data is actually stored in there.

Best regards,

Jarle Ekanger, MSc, PhD, CLD
Flow Design Bureau AS

- "The resistance of wires in LabVIEW is not dependent on their length."
0 Kudos
Message 2 of 6
(2,802 Views)

Hi Jarle,

 

I am not able to run the TDMS file viewer down on the RT target, but I have FTP the file to the host PC and then run the TDMS file viewer. The file viewer show only the single data point as shown in the TDMS read after the close.

 

Rhys

0 Kudos
Message 3 of 6
(2,795 Views)
I can't run your VI locally and failed to reproduce the issue with my mockup. Can you reproduce this issue again, produce a TDMS file with small size and upload it to the forum? We'll check whether this file is sane or not.
0 Kudos
Message 4 of 6
(2,712 Views)

Hi,

 

You can refer Figure-3 of:

 

http://www.ni.com/white-paper/3727/en/

 

Regards,

 

DCKAN


Best Regards,
DCKAN

"We make a Living by what we get. We make a Life by what we give."
0 Kudos
Message 5 of 6
(2,689 Views)

@Rhys_CKTC wrote:

Hello,

 
 
Any help would be greatly appreciated.
 
Rhys

OK You have several problems with that code that are contributing to your race condition.

 

First: look at the top loop! You place the same file path on two different shift registers (Without an Always Copy! DANGER!) and one of those SR's is fed by a tunnel using the "Use Default If Unwired" option- And not every case is WIRED!  WORSE! It is this SR that actually writes to the terminal for the filename!  Insanity must have kissed you just before you wrote that state machine  (Humor intended-  I've seen code with "Please-Just-one-more featureitis" before and have made simillar mistakes)

 

Now lets look at the logging loop: You obviously realized you had a race condition and created the case to wait for log file path to not be empty.  by reading a local variable!  A LOCAL to CURE a race condition!!! Smiley Surprised What were you thinking!  then of course when the file path is not empty you change state to the opaen file state and IGNORE the path on the shift register and READ THE LOCAL AGAIN!

 

Initialize your log file path before you start any other code loops and you may keep what little hair you may have (I'm almost certain you have pulled out handfulls from your head by now!)  You know Its the right thing to do since you have a Sequence Structure out there running parallel to the logging loop that actually WRITES the offensive local.

 

You may have other nasy habits as well- I just followed the file path!

 

Now smile- we've all done something like that at least once!


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 6
(2,676 Views)