DAQmx .NET in TestStand

[ebalci]

Hi,

I am having problems while calling DAQmx functions from TestStand using .NET adapter. The device I am programming is PXI-6704.

According to the function either the step fails to perform its mission or returns error.

Case-1: the digital input function DAQmxReadDigitalScalarU32:

I created 2 steps calling the same function above. The only difference is first one is calling it from a dll (using C/C++ adapter) that I created in CVI using NIDAQmx.h and nicaiu.dll and the second is calling it from the .NET dll provided by NI website using .NET adapter. While the C/C++ dll reads the input correctly (0x10) the .NET step always returns 0x00.

Case-2: the analog output function DAQmxWriteScalarF64:

Again I created 2 steps calling the same function above and the steps are as described in Case-1.  While the C/C++ dll generates the output correctly the .NET step returns the error code -200492 which means "reserved parameter not null". The funny thing is the .NET adapter does not see a reserved parameter when the function is selected from the drop-down list but this function (as seen from its function panel in CVI) has such a parameter.

I attached the dll's and a sample sequence that demonstrates Case-2.

Anyone kind enough to try it needs to modify the function calls according to the device name in his/her hardware. In my case the card is standing in slot-10.

I guess either I am doinf something wrong or the DAQmx .NET library has some flaws in it.

Any comments?

Message Edited by ebalci on 05-11-2007 10:52 AM

[Jennifer O]

Hi Ebalci,

My first recomendation would be to separate what you are trying to do into two separate operations.  This will be much more efficient in the long run, and will help you to debug along the way.  If you make calls to dlls directly from TestStand, you will be repeatedly having to go out to a dll and return information to TestStand.  It would be more efficient to code what you would like to do in the .NET environment, and then make a single call to your application.  This will also help you debug the application without introducing an extra variable.

Secondly, I am not sure where you have obtained the dlls that you attached in your post. The native .NET dll will be named "National Instruments.DAQmx.dll". I believe this is what may be making this issue more complicated than necessary, since neither dll is a National Instruments dll.  I recommend either using the C API or the .NET API but not both.  If you choose to code your application in C# or VB .NET there are plenty of examples already written, which may help you save some time in coding.  There are also some great resources which will install with the DAQmx .NET support.  This includes the NI-DAQmx .NET Framework #.# Help (where #.# will be 1.1 or 2.0 depending on the framework you are working with). You can use all of these resources for reference to code your application.  The examples for ANSI C will install into C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C.  If you have chosen to install support for Visual Studio you will get the native .NET DAQmx API.  This will install by default, examples into:

C:\Program Files\National Instruments\MeasurementStudioVS200x\DotNET\Assemblies\Current with examples located in
C:\Program Files\National Instruments\MeasurementStudioVS200X\VCNET\Examples\DAQmx.

For more information on programming options with DAQ and C++ see Programming NI-DAQ in Visual C++.NET.

It looks like from your code that you are working with the ANSI C calls and not the .NET API.  However, the wrapper/adapter that you have does not provide the complete ANSI C library.

Regards,

Jennifer O.
Applications Engineer
National Instruments

[ebalci]

Hello Jennifer,

Thanks for the reply. This is the second time I get the suggestion to NOT to call each function separately from the dll. So I'll stick to it.

You wrote: "...Secondly, I am not sure where you have obtained the dlls that you attached in your post..."
Well, I remember downloading the .NET library dll from NI website (either a forum or an article).
I compiled the other dll (that I called in the C/C++ step) myself in CVI by following a thread in this forum. That's why its information does not say NI.
It is actually a "wrapper" of the nicaiu.dll in <system32> directory.
You open the NIDAQmx.h file, go to Options>Generate DLL Import Library in CVI, point to the nicaiu.dll file and compile a dll which is 'compatible' with TS. By compatible I mean that the functions and their parameters in the dll are recognized by TS in the Specify Module dialog box.

Now I think, I'll stop using the .NET dll that I have posted.
The wrapper library is missing some functions, I am aware of that. They are the ones with variable number of parameters. But the available ones are functional.

I am a CVI-person actually and I have no problems at all using the DAQmx C library. That was the point I started with, but then I was tempted to use TS whereever possible and reduce the coding. Now, as you pointed out, this may not be a good idea.

Thanks again Jennifer.