Error -2500 with write to TDMS file from executable

[george seifert]

I sure hope someone can help. NI seems totally stumped. I don't know exactly what caused this but now I get this error when my executable (Windows XP, LV 8.2) tries to write to a TDMS file.

Error -2500 occurred at TDMS Set Properties in <my VI>.

Possible reasons:

LabVIEW: Storage VIs internal error.

I've run the debugger and I can see that the code gets past creating the TDMS file, but errors when trying to write to the file. I replaced the Set Porperties write with a different write to the TDMS file and still get the same error. This same error also happens on another executable that was built earlier.

NI thought it might have something to do with DAQmx 8.5 so I replace that with DAQmx 8.3.1. No luck. So I removed MAX and it's components. This also seemed to remove LV 8.2 so I reinstalled that and MAX and DAQmx 8.3.1 and VISA 4.1. Still get the same error.

I think this started when I had to go into the registry to remove an old reference to DAQmx 8.1 after installing DAQmx 8.5. My installer builder kept trying to find something in the DAQmx 8.1 installer directory even though it was no longer installed. My registry edit fixed that problem, but I fear it may have caused this other problem.

Any suggestions? I'm dead in the water here and NI doesn't seem to have a lifejacket for me.

George

[JodyK]

I had an issue with upgrading to daqmx 8.5 and an executable with TDMS stores. It had to do with the 8.2.1 Runtime engine vs the 8.2 runtime engine. Also Daqmx 8.5 installs and old version (1.00??) of the storage VIs. I completely wiped all NI stuff of the machine and reloaded daqmx 8.3 and the 8.2 runtime engine and it worked again.

-Jodyk

[Herbert]

More details on ni.com.

Herbert

[Herbert]

The issue appears to be caused by an incompatibility between the TDMS functions in the LabVIEW 8.2 and 8.2.1 runtime engines. Unfortunately, we do not have a workaround for this problem. I'm not sure how well uninstalling DAQmx versions / runtime engines and replacing them with older versions works. That sounds like the kind of thing that might not work as smoothly as it maybe could (uninstalling DAQmx might leave the installed runtime engines untouched / reinstalling 8.2 runtime might not do anything if 8.2.1 is present / runtime engines for recent LabVIEW versions cannot be uninstalled in the Windows Control Panel etc.).

Details on this particular issue:

• An application that uses TDMS and is compiled with 8.2 will only run with the 8.2 runtime engine. It will not work with DAQmx 8.5 (or higher) installed, since this updates the runtime engine to 8.2.1. The runtime engines for 8.2 and 8.2.1 cannot coexist on one machine.
  
• If your application requires DAQmx 8.5 to be installed, the only way of getting things running is to compile your application with LabVIEW 8.2.1.
  
• For the same reasons, an application compiled with 8.2.1 will not run with the LabVIEW 8.2 runtime engine.
  

The issue can result in several different errors coming from any one of these functions: TDMS Write, TDMS Read, TDMS Set Properties.

Probably the worst birthday present ever.

Sorry George!

Herbert

[Kevin P]

Herbert,

Thanks for the support you give on the TDMS functions. I'd like to verify something before going much farther on a new app.

I've already developed an app under LabVIEW 8.20 and DAQmx 8.3 which depends on TDMS data storage. It's now out in the field and under config control -- i.e., no unnecessary changes allowed. I'm about to make a very slight variation of that app but will need to develop with a different PC and a new LabVIEW license (long story -- contracts, accounting, etc.). I expect that I'll be receiving LabVIEW 8.2.1 and DAQmx 8.5.

I'm planning to make a stand-alone utility for reading, viewing, and exporting portions of the TDMS data. I'd like to be able to deploy this stand-alone app back to the older computer out in the field. What are my options? I'm thinking it's something like:

1. Talk to NI internal account people so I can install older LabVIEW 8.20 on my newly purchased license rather than 8.2.1 (Would also install DAQmx 8.3 instead of 8.5). This seems like an easy way to be sure that my stand-alone executable will be compatible with the older deployed PC.

2. Go ahead and install LabVIEW 8.2.1, but stick with DAQmx 8.3. Then I'd be building an 8.2.1 executable that I want to deploy to an older PC with 8.20 runtime. Will this work, both in general due to runtime version difference and in particular with respect to the TDMS functions? Bear in mind that the older PC is creating the TDMS files with a LV 8.20 app.

-Kevin P.

[Herbert]

QUOTE(Kevin P @ Jun 19 2007, 10:50 AM)

1. Talk to NI internal account people so I can install older LabVIEW 8.20 on my newly purchased license rather than 8.2.1 (Would also install DAQmx 8.3 instead of 8.5). This seems like an easy way to be sure that my stand-alone executable will be compatible with the older deployed PC.

2. Go ahead and install LabVIEW 8.2.1, but stick with DAQmx 8.3. Then I'd be building an 8.2.1 executable that I want to deploy to an older PC with 8.20 runtime. Will this work, both in general due to runtime version difference and in particular with respect to the TDMS functions? Bear in mind that the older PC is creating the TDMS files with a LV 8.20 app.

Kevin,

the second option will not work. The executable needs to be compiled with the same version the runtime of which you are using. The incompatibility is not in the TDMS files, it exists between LabVIEW-compiled code and the LabVIEW Runtime Engine. So, I'm afraid the first option will be the only way to go (except for updating everything to 8.2.1, regardless of the DAQmx version).

Herbert

[Kevin P]

Herbert -- still out there?

I've been staying with 8.20 rather than upgrading to 8.2.1. But what's the situation now with 8.5? Could I now develop in 8.5, then back-deploy an 8.5 executable to my older system that's currently at 8.20? Thanks for any tips.

-Kevin P.