Are there LabView VI's for accessing and writing data to a CDF?

[MDN]

I am currently trying to develop a data acquisition system using LabView to acquire the data and to write the data to a file in NSSDC's Common Data Format (CDF). The CDF distribution (Windows 2000) comes with a precompiled dll of the CDF library of functions. Unfortunately, LabView crashes when I try to use the Call Library Function node. I am confident that it is not a function prototype error, but it may be that the CDF library is not thread-safe.

Has anyone developed VIs for writing and accessing data in CDF format?

Does anyone know how I can determine why the Call Library Function node causes LabView to crash when it uses a particular dll? There are a host of reasons given in the "Using External Co
de" manual, but no apparant way of determining which one is the culprit.

[Randy_H]

MDN,

You are correct, it could be many things that are causing the DLL to crash. If you do not have the project and/or the soucr code, then there is not a lot that you can do about it. My suggestion would be to write a DLL wrapper for this DLL and have LabVIEW call your wrapper DLL. This would be my best suggestion for now. You may also want to contact the creators of the CDF DLL and ask them what their build parameters are or if they have tried their DLL with LabVIEW.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[MDN]

Thank you for your response. Actually, I have solved the problem by recompiling the source code for the CDF distribution using the Cygwin development environment. Cygwin provides a unix C compiler and linker which can create Windows executables and dlls. After modifying the makefiles that came with the CDF distribution I was able to build the dll and then use the Call Library Module to access the CDF functions.

A note about this process: the linker that Cygwin exports both Windows-style and C-style functions when it creates the dll. Be carefull not to use functions that end in underscores from the CDF dll as C-style functions.

Also, I would like to point out that the current faliure method of the Call Library Module (i.e. crashing LabView) is not acceptable.
It would be much better if LabView would generate an error message or an error log entry in case of a dll failure. I would hope that this scenario would be a target goal for future development of LabView. The Call Library Module is an incredibly powerful tool in that opens up many avenues of development -- it deserves a better way diagnosing problems.

[Greg_McKaskle2]

....

> Also, I would like to point out that the current faliure method of the
> Call Library Module (i.e. crashing LabView) is not acceptable. It
> would be much better if LabView would generate an error message or an
> error log entry in case of a dll failure. I would hope that this
> scenario would be a target goal for future development of LabView. The
> Call Library Module is an incredibly powerful tool in that opens up
> many avenues of development -- it deserves a better way diagnosing
> problems.
>

For performance reasons, the CLF doesn't spawn another process, but
takes place in the LV process. That means that anything that the DLL
function does could affect the LV process.

You don't mention what version of LV you are using, but
LV 6.1 now
defaults to catching exceptions around the DLL call. It doesn't protect
from crashes following the call due to memory corruptions, but it does
catch many that previously crashed due to bad parameters or bad calling
conventions.

Greg McKaskle