NIDAQmx .NET library missing function

[ebalci]

Hi,

I am planning to use the NIDAQmx .NET library to control the devices in my PXI chassis over TestStand.

I add a .NET step and use the DLL that I downloaded from the NI website.

However, some functions are missing, like SetAnalogPowerUpStates. Is this function exluded deliberately because of its variable parameter count?

Before the .NET module I tried to use the ANSI C library, NIDAQmx.lib. That function appears with the name "SetAnalogPowerUpStates_VB6" and when the step calls this function, a run-time error occurs with error code -17502.

So, it looks like there is no direct way of calling this function from TestStand?

Any comments?

[Brandon_V]

This is not recommended architecture, these DLLs and Assemblies are meant to be called from other environments and not directly from TestStand. TestStand is a Test Management software and is not meant to be a programming language. You should always program your test steps in code modules and call these code modules from TestStand.

[Matt_A]

Hello S. Eren BALCI,

The SetAnalogPowerUpStates function does not exist in the .NET framework. Instead, .NET has the SetDevicePowerUpState method which acts on a DaqSystem object. To use this method you would need to instantiate a DaqSystem object and then call the SetDevicePowerUpState method on this object. For more information about using NI-DAQmx in the .NET Framework I would recommend that you view this KnowledgeBase.

[ebalci]

Hi Matt and Brandon,

Thanks for the reply and the suggestions. Before I starting to develop the project I really struggled to find the correct architecture.
We have a 14-slot PXI system (all slots accupied) along with lots of power supplies and stuff.
The driver variety was frigthening at first : C/C++ dll's, IVI-C, IVI-COM, even some .lib files including the DAQmx C library.

So, I thought that's what TestStand was meant to do. All these different component technologies can be used in a single standard environment.
I do not generally try to avoid coding but I admit that the ease of use tempted me.
At first it did not feel completely right to me either. However, after a few trials I saw that it worked and I convinced myself that this is a correct way of doing it and the bad feeling is because I did not do it this way very often.

So, Brandon, what is the main cause of not doing it this way? Is it  just a feeling or have you seen cases where such an aprroach result in problems?
Thanks again,

[ebalci]

Matt,

When I specify the module as the .NET DAQmx dll in TS, only two classes can be seen in the list: NIDAQmx.DAQmx (only action available is Call Method) and NIDAQmx.DAQmxConstant (only action available is Get Property). The methods and properties in these classes are all marked as static in the drop-down list.
Doesn't that mean that I should call them without an object instance?

Actually, I tried to use the library in a simple application to read some digital I/O lines, some functions work like reset, create task, assigning channels but some don't work, like reading digital input lines, generating analog output voltage.
I could not find the SetDevicePowerUpState method that you mentioned in the list.
It looks like we are not talking about the same dll.

I attached the one I am using in a recent post of mine, which is about the DAQmx .NET library.
Here is the link : http://forums.ni.com/ni/board/message?board.id=330&message.id=14955#M14955

Message Edited by ebalci on 05-14-2007 08:44 AM

[Brandon_V]

The main reason to not code directly in TestStand is for debugging purposes. It is always recommended to debug your code outside of TestStand first, as if there are any problems in the code itself you can catch them very quickly. If not, it is very easy to bump into problem in TestStand later. When you take the code modules out of TestStand and begin using it as a programming language, you take out this way of debugging and finding problems in code becomes a lot more cumbersome.