08-24-2015 08:24 AM
Hi,
I wonder if there is someone who can cut out corrupted entries from TDMS?
There is a continuous measurement with logging into TDMS. The measur. software is in LV 2012.
On a very rare occasion (I suspect lock by some antivirus) the TDMS gets corrupted, but keeps writing (without error in the cluster) into the file over the following sequence:
When the file is opened after the measurement, only x of first data entries are shown. (A legacy text output shows all data). Diadem and the native VI for Viewing TDMS show the rest of the data mashed into one channel (called OutputIndex below).
Excel import returns code (-2503) (not a TDM file or similar). TDMS Defragment returns the same. Open and Close VIs return no errors.
I upped the TDMS here: ftp://ftp.ni.com/incoming/vojtest28.tdms
Thanks
c.
Solved! Go to Solution.
08-25-2015 02:47 AM
Hi!
First of all I would like to ask you, to send me a little bigger piece of code. I suspect, you are writing this sequence in some kind of loop, right? If so, make sure, the error cluster there is changed to shift register and try not to open the file every iteration, but open it before loop take the reference inside the loop, and close the file after the loop stops. It's much, much better practice to do so:) If it still doesn't work, please send me more code.
As to the cutting out the corrupted entries from TDMS, I'm not sure if it is possible (probably yes, but in a very complicated way). Better to be sure the writing process is correct.
Best regards
08-25-2015 04:20 AM
Hi Marcin,
thanks for answer. Well, my apologies, I have to admit the error wire was not in shift register:
This above is repeating according to how many data entries are written. I also don't like to have the file opened and closed on every iteration. But out of legacy reasons I'm trapped with this for now.
Anyway, the following VI called on my corrupted TDMS does not produce an error:
So thanks again, I'll see to the error handling and hope to learn about corrupted data in time.
08-25-2015 06:21 AM
Except the error handling and opening, closing the TDMS file th code looks ok. So, let me know if changing to shift registers helped you. You can do some error handling on the end of the loop - if an error occurs just stop the for loop or something like that.
In my opinion the most probably reason of corrupted files is opening and closing file each iteration... If you can't change it, maybe try to add some wait function in the loop? Start from the high values (100 ms) and go lower and check when the error still exists. It's a work around but if you can't change opening and closing file it's my only idea at the moment...
If you can, please upload the tdms file again, because I can't download it, I don't know why.
And the last thing is my small advice 🙂 try to maintain the wires as straight as possible - especially in such a simple cases like en error wire on the beginning on the loop: you are going down with the wire, enter the case structure, enter the for loop and then again up, why not to put it straight? 🙂 It always easier to debug and read such a code.
Best Regards
08-25-2015 06:57 AM
Hello again,
you don't need to upload the file again, I was able to download it:)
My colleague advised two things you can try:
1. Try to enable buffering (http://zone.ni.com/reference/en-XX/help/371361M-01/glang/tdms_file_open/ - false in disable buffering input)
2. Consider to add exception for folder you ar using to store the data in your antivirus.
Let me know if it helped you:)
08-25-2015 08:45 AM
Hi Marcin,
those are good points, I'll try those. I also inserted there a defragment TDMS VI that was at least trowing some errors. That way I might learn about the data corruption if it slips past open-close. It is very rare, but I might live with that now. 🙂
Thanks,
c.
08-25-2015 08:47 AM
I'm really glad I could help you 🙂 Good luck with your work!