Does anything need to be added to a dll that is not required in an executable to create a DAQmx task successfully?

[duncan carter]

Does anything need to be added to a dll that is not required in an executable to create a DAQmx task successfully? I have no problem making an .exe that creates a DAQmx task but I get floating point errors in DAQmxCreateAIAccelChan when I attempt to do this in a dll. One example is in the following autogenerated code.

/**************************************************************************/
/* WARNING: This file was automatically generated. Any changes you make */
/* to this file will be lost if you generate the file again. */
/**************************************************************************/
#pragma DisableUnreferencedIdentifiers
#include
#include

#define DAQmxErrChk(functionCall) {DAQmxError = (functionCall); {if (DAQmxError < 0){goto Error;}}}
#define DEFAULT_TIMEOUT DAQmx_Val_Infinite
#define ONE_SAMPLE_PER_CHANNEL 1
#define DEFAULT_DATA_LAYOUT DAQmx_Val_GroupByChannel
#define DEFAULT_FILL_MODE DAQmx_Val_GroupByScanNumber
#define SINGLE_ELEMENT_SIZE 1


/**************************************************************************/
/* Begin Generated Code */
/**************************************************************************/
int32 CreateDAQTaskInProject(TaskHandle *taskOut0)
{
int32 DAQmxError = 0;
TaskHandle taskOut;

DAQmxErrChk(DAQmxCreateTask("DAQTaskInProject", &taskOut));
// floating point error occurs in the following call
DAQmxErrChk(DAQmxCreateAIAccelChan (taskOut, "Dev1/ai0",
"Acceleration", DAQmx_Val_PseudoDiff, -5, 5, DAQmx_Val_AccelUnit_g,
1000, DAQmx_Val_mVoltsPerG, DAQmx_Val_Internal, 0.001,
""));

DAQmxErrChk(DAQmxCfgSampClkTiming(taskOut, "",
1000, DAQmx_Val_Rising,
DAQmx_Val_FiniteSamps, 100));

*taskOut0 = taskOut;

Error:
return DAQmxError;
}

/**************************************************************************/
/* End Generated Code */
/**************************************************************************/

[David Mc]

Hi Duncan,

You might want to consider posting this question in the Multifunction DAQ discussion forum where the users are more familiar with DAQmx development using C.

David Mc.
NI Applications Engineer

[duncan carter]

I submiited this to support by email and have corresponded with Spencer Stock including posting a test program that calls the dll along with the dll. I posted this in the CVI forum and somehow got it here in error.

Duncan

[duncan carter]

I received the following response from NI support on Oct. 14, 2004.

Title:
Can I Make NI-DAQmx Calls From Borland Delphi?


Problem:
Because making DAQmx calls directly from Borland Delphi is not supported
I've created a wrapper DLL in Visual C++ that makes DAQmx calls instead. I
should be able to call this DLL from Borland Delphi but I receive error
-50251 at one of the DAQmx function calls as soon as the DLL is called.
However, the same DLL works properly when called from Visual C++. Why is
Borland Delphi not able to handle parameters passed from the wrapper DLL
that makes calls to the DAQmx driver?


Solution :
Making NI-DAQmx calls from Borland Delphi is not directory supported.
However, you can create a wrapper DLL to call NI-DAQmx from Delphi, but you
may run into the previously mentioned problem unless you mask some
exceptions that occur when passing floating point numbers. Apparently, this
happens quite frequently when Borland-built applications use components
built with non-Borland compilers. For example, when you try to use OpenGL
from Delphi, the same type of thing will happen. Most compilers manage
floating point error conditions internally under defined rules. However, a
number of compilers will always unmask these exceptions in order to enable
the compiler's proprietary error handling mechanisms. Borland Delphi by
default exposes these errors and certain calls to DAQmx return floating
point conversion errors that cause the DLL to crash. To handle these errors
one must hide or mask the handful of different error cases that might be
encountered. If you fail to mask the exceptions, they make their way to the
operating system which will display an error message and then shut down the
DLL.

The InitializeFPU procedure below will mask all FPU exceptions, so you
should do this before calling any DAQ function.

procedure IntializeFPU;
asm
finit
wait
end;

If their Delphi application requires that FPU exceptions be unmasked, then
they can do this immediately after returning from the DAQ function.

fninit
wait
fldcw word ptr [Default8087CW]
ret