TDMS File Not Appearing on Flash Drive (cRIO-9076)

[ScottKenyon]

Hi Everyone,

I have an application where I am recording temperature data via a CAN card (9853) and thermocouples (9211). Once this data is collected, I build an array out of it (totaling 16 channels), and write it to a TDMS file. When my chassis connected to my host PC and I run, everything works as expected - I get a TDMS file on my flash drive (written to the path U:\file_name.tdms) with all of the collected data. However, when I build an application, deploy, and run stand-alone, the flash drive will intermittently not seem to write anything. This is evident by the file not appearing on my flash drive after powering down the chassis, removing the flash drive, and checking on the host pc.

I've tried a variety of troublehshooting techniques, but the most recent left me quite discouraged. I used the "File Exists" block to toggle an LED on during the write TDMS operation. In stand-alone mode, the LED turned out, suggesting the file at "U:\file_name.tdms" existed and was being written to. However, checking the flash drive, there is nothing to be seen. Again, this only occurs when I'm not connected to a host. I've tried multiple flash drives. You'll see in my screenshot that I even tried to force the tdms file to be created (again) if it didn't exist already. All signs point to it being there and being written....but why isn't t appearing sometimes? And why does it appear sometimes? 

Thanks for the help,

Scott

[James.M]

You say "LED turned out", which means the LED was false. So wouldn't this mean the File was NOT found? How does this point to the file existing and being written to?

Make sure that the flash drive is always being assigned as "U:\". It might be being assigned a different letter whenthe host computer isn't connected.

[ScottKenyon]

James, thanks for the response.

I may have worded it poorly. The "Check File Exists Block" gives me a boolean: True if the file exists, false if the file doesn't exist. I convert this boolean to a 0/1 and wire it to the input of RT LED block, which turns off the LED for a 0 and on for a 1. The LED lights up at the beginning of code execution, suggesting to me that the file absolutely exists.

I hadn't considered your second point.....is there a way to check what letter is assigned in a host vs. non host connection scheme?

[James.M]

Well if the file does exist like it seems now, the directory letter is probably correct.

When I have done a standalone cRIO project in the past, I always created a log file in the root directory for debugging purposes. I would suggest you try writing status info to a simple txt file in your root directory and writing any errors that might occur as well.

[ScottKenyon]

Thank you for the advice, I'm going to incorporate that this afternoon/tomorrow. I appreciate your support.

[James.M]

No problem, please report back once you figure out the issue and let us know here. This will help others in the future solve their problems especially if you throw some Marked Solutions and Kudos around.

[ScottKenyon]

I still don't have a clear solution, but I think I've determined this much: there's a relationship between either the prior existence of the file I am trying to write to, despite choosing the "open or replace" enum on the open TDMS vi OR the mapping of the USB drive changes based on whether or not the chassis is connected to a host (but not deployed through the Labview project). I didn't have time to experiment with both possibilities; I found a sequence of powering up the 9076 with the flash drive, waiting ~30 seconds and letting it start writing that worked.

If I ever determine the root of the issue, I'll surely update this thread. Thanks for the support.

[James.M]

Oh noooo, my nightmare from 1 year ago has returned!

I had a similar problem, where the only solution was to give the cRIO an extra 30 seconds before doing anthing. I don't think I ever had a problem with the file I/O right off the bat, but maybe that's just because I wasn't trying to write to a USB drive.

An alternative to waiting an arbitrary 30 seconds would be looping continuously and checking for the drive each iteration. Once the drive is writeable, then continue. This may not work if you're seeing a True value for File Exists though...