I have a cRIO-9073 controller on which I am streaming analog input data at 40kHz from a 9215 module into a local TDMS file. Data collection is triggered via a switch on a front panel -- turn the switch on and it starts recording the A/I data and streaming to disk, turn the switch off and I shut down the A/I and close the TDMS file.
Everything seems to work fine but occasionally when I turn on the data collection switch I will get an error -2519 (LabVIEW could not load the TDMS file component) from the TDMS Open call. If I turn off the data collection switch, then turn it back on, the next call to the TDMS Open function hangs and never returns.
During this time I can see that other functions in my VIs are continuing to execute (other lights & values on my front panels continue to update), but I cannot stop the VI from within Labview on my windows development system -- hitting the stop button doesn't do anything. It seems that the only solution is to reset power on the cRIO controller.
Does anyone have any more details about this error -2519 or ever seen any problems with the TDMS Open function hanging?
TDMS Open hanging certainly sounds like a bug. Your application might work fine though if we make sure it can find the TDMS component. On a cRIO device, that would be a file called "tdms.out". Could you ftp to your target and see if that file is there? If it is not, we could try to manually copy it from your "RT Images" folder to your target. That should have happened automatically. I'm not sure under what circumstances it would fail.
Yes, the tdms.out file exists on my target system. In fact, after I start up my VI when I turn on data collection everything seems to works fine, it's only after I stop and restart data collection a couple times -- maybe only once, sometimes 20 times -- that I first get the -2519 error and then subsequently see the TDMS Open hang.
The TDMS component will leave memory when it is not needed, so if you don't have any open files at any point in time, it will be unloaded. Sounds like there might be a problem with that. You could check for that by opening a new file when your application starts and keeping it open all the way until your application is done, but without ever writing to it. That way, the component wouldn't get unloaded. The overhead caused by this is very low, so worst case, this might be a possible workaround.
Hope that helps,
I did as you suggested and the number of problems that I have has significantly gone down. I can't say the problem is totally resolved because I've seen 2-3 instances of my system hanging in the last week that I can't otherwise explain, but certainly it runs 100 times more reliably than before.
Just to add a bit more information, I was having a similar problem except the application (both Labview dev environment and the app executable) was crashing. Searching Window's application log turned up this notice:
Faulting application name: LabVIEW.exe, version: 10.0.0.4032, time stamp: 0x4c24f059
Faulting module name: tdms.dll_unloaded, version: 0.0.0.0, time stamp: 0x4c91c585
Exception code: 0xc0000005
Fault offset: 0x3505eff8
Faulting process id: 0x1e4c
Faulting application start time: 0x01cbbdc6da377ab1
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2010\LabVIEW.exe
Faulting module path: tdms.dll
That exception code is an invalid memory access error. Looks like tdms.dll was being unloaded in the brief time between closing a file and opening a new file but LV didn't quite keep up. In any event, the workaround Herbert suggested stopped the crashes.