cRIO unexpected shutdown during TDMS writing

[LuisPadua]

Hello,

I have an application running standalone on vehicles and it is logging data into TDMS files by shift (6 AM to 5PM and 5PM to 3AM). Unfortunately, I don't have control of the power of equipment and sometimes the users cut off vehicle power.

cRIO reboot and operates "normally". But when I collect the data, the TDMS has the same size of a normal shift, but when loaded in Diadem, I can see only data till the moment the power was interrupted.

Is there a way to recovery this data?

Thanks

[Craig_]

How does your application handle the case where there already is a TDMS file at the location it is trying to save?

Ideally if it does see that there already is a file on the drive it should create a new one or append to the existing one.

[LuisPadua]

My application only create new files when there's a change in shift...
Openning and closing sames files are Ok when there is no suddenly shutdown...
I will create an file error handler on cRio build...
In this meantime,
I put this topic on Diadem, cause, at this point, I've a lot files corrupted and I would like to restore them...
Thanks

[Craig_]

If your target is getting turned off a lot while taking data it may be worth it to call the TDMS flush function throughout your application to minimize lost data. Alternatively if the amount of data being saved is relatively small you could implement a function which writes blocks to the file and closes the reference each time.

Good luck!

[LuisPadua]

Craig,

My samplerate is low so I use the flush function every acquisition. 

What I really need help is if it is possible to recover the sample I wrote after I corrupted the file.

I know that I'm still writing into the file cause I see the TDMS file size increasing while it is running after the shutdown.

Thanks

Luis

[Craig_]

It sounds like you are writing back to the same file after the reboot. I would definitely create a new TDMS file if one already exists rather than attempting to append to a possibly corrupt file.

To clarify, it sounds like the data can be read from the file up until it shuts down. On reboot it appends to the existing file but nothing can actually be read from it from the shutdown point on. Is this correct?

[LuisPadua]

That's exactly my situation.

I'm aware that my cRIO application needs to change, to avoid writing into a corrupted file. 

But, I still have a lot of files already logged, that has useful information that I can't read. These files opens at DIAdem only till the moment the cRIO was turned off.

[Otmar]

Luis,

Can you make the data available to someone on my R&D team so we can look into recovering these?

How many files are there?

If we can create an automated way to do this I'm happy to provide some help, if it's a manual process and there are "a lot" of files, this is getting to be a difficult request for me to get someone to work on.

Can you provide a few files to me to allow my R&D team to look into?

      Otmar

[LuisPadua]

Otmar,

The files from my tests are larger than 6mb, but I simulated the fail... on this file attached.

You will see a time stamp channel till 2:06 PM, at this moment, we cut the power... and turn on the cRIO again...

after reboot, we check through ftp that the file size was increasing, it means that cRIO was doing the WRITE TDMS function...

 Then, we interrupted the file correctly. You can see at WinExplorer that the last modified date is 2:16

I appreciate any feedback you can give for me apply on my tests,

Thanks

Luis Padua

[Tianbin_Xu]

Hi Luis,

When you cut the power at 2:06PM, the .tdms file is incomplete/corrupt at that moment, so the data appended after cRIO rebooted is also corrupted.

For your use case that power failure might happen, I would recommend you delete the .tdms_index file every time before TDMS Open in your application (especially after a power failure reboot), because .tdms_index sometimes can prevent errors(e.g., indicating file corruption errors) during TDMS Open.

By removing the .tdms_index file, your application is likely to get a error during TDMS Open, this will stop your application appending new data to a corrupt file at right point.

BTW, could you please give us your test application VI and the .tdms file generated before 2:06PM power cut to verify my theory?