TDMS logging on RT

[zial]

Hello,

I am trying implement an RT application which reads 20 channels simultaneously at the 50kHz
frequency. The application will run 3 hours that means it is a lot of data for storage.

I am using the PCIe-NI6353 DAQ card in PC configured as a RT machine and I am programming this application in CVI/Win. I need to send the acquired date to the host computer (of course not all data but only in a 200ms loop) but all data (20chan/50kHz) to log to disk on RT target.

I have a question about logging function. I exploit the function
DAQmxConfigureLogging(taskHandle,"c:\\example.tdms",DAQmx_Val_LogAndRead,"data",DAQmx_Val_CreateOrReplace)); which streams raw data from buffer to the disk.

I think that this is not big problem to save so big file but What will be happened if the RT target
falls down (for example because of power supply) in middle of 3 hours time. Will data be saved on the disk or will be lost. I have read the help for TMD streaming where it is written that data is written directly to the disk. I have tested it but I am not sure if that is true. I had simulated a mistake in my application and then I could read this file. May be because application didn't close the file.?.

Can you explain or help me with solving this problem?
Should I program the logging alone in my application and so to avoid these problems.

Thank you in advance.

Ales

[AndrewMc]

With the DAQmx integrated logging feature, data is constantly written to disk.  The software is designed to be as fault-proof as possible with respect to incomplete files.  For example, if a file is in the middle of writing and the power is pulled, when trying to read the TDMS file, it will read whatever of the file that it can.

That being said, it's important to note that while our software might try to recover, the file system might not be able to recover as well.  In the case of power loss, I've seen some issues where an operating system was reporting 0 kb file size even though data had definitely been written.

Long story short, the software for streaming to disk and for reading/interpreting the file are pretty robust for this case, but my concern would be the file system itself in these situations.

[zial]

Thank you for answer.

OK, I understand that data are directly stored on disk. Could I read the data in spite of the fact that the file isn't closed? Becasue if I want to read the files through the FTP, I can see only 3kB size of the file althought the file is more bigger in fact and I can't copy the file to a host computer too.

May be, if I opened the file and read it, then I could read all stored data.

Thank you for answer again.

[zial]

Thank you for answer.


OK, I understand that data are directly stored on disk. Could I read the data in spite of the fact that the file isn't closed? Becasue if I want to read the files through the FTP, I can see only 3kB size of the file althought the file is more bigger in fact and I can't copy the file to a host computer too.


May be, if I opened the file and read it, then I could read all stored data.

I don't remember if the file system of RT target is FAT32 or reliance. Can be this a problem? I suppose that I have formatted the disk with FAT32.

Thank you for answer again.

[AndrewMc]

Sorry for not responding sooner. I was hoping that somebody more familiar with the RT OS could comment.

From what I remember, the file system there is FAT32. I wouldn't be too surprised if the operating system or the file system don't tolerate power loss while writing to a file well. I'm sure that the integrity of your other files is absolutely maintained, but how the caching and file system work for that one file, I'm just not sure.

In any case, I would fully expect that the behavior would probably be the same regardless of what file type you're writing to or how you're writing it.

If the file ends up not working, you could consider doing the file I/O "manually" and frequently starting a new file. As it is, we do not have the capability to split between multiple files with the integrated logging solution *yet*.