dll for NI 6008 in teststand

[RamonaL]

The DAQmx DLL you are talking about just contains the low level driver functions of the DAQmx.

If you want to access these functions you will need some code module like CVI to access these functions and define what exactly you want to do. As you saw TestStand can not do it - its not a programming language as C or .NET etc. So you can not access the functions you want to use.

Yes, you will have to create a DLL or .NET assembly in other language.

Cheers, RMathews

EDIT:

So I am pretty sure that these other DLLs you got from other vendors, are wrapper dlls. So these dll calls other dlls (the "drivers"). The DAQmx dll is not a "wrapper" dll. It contains the communication with the hardware. You have to define the communication accessing to the DLL. This you can only do in a programming language like CVI.

[dotNet_to_LabW]

Hi,

Thanks..your last reply was convincing.

I got it now.

Greetings

RB

[RamonaL]

😄

[qwertyuiop1]

I however am NOT convinced. I am new to TestStand.

As stated above, HP and Agilent (and even mister cheapo relay-board) provide dorNet assemblies which can be called directly from TestStand to do something useful. I cannot believe that if I buy a top-of-the-line data acquisition system from NI that NI's own test sequencer cannot control it. If a "wrapper" is needed, I expect NI to provide one. (I don't think it is needed though... I can see the classes and properties inside the DLL from TestStand.) Yes I know I can write one in CVI or Visual Studio, but I shouldn't need to.

NI won't help because the 1 year free support we got with TestStand has expired. Please, somebody out there must have done it. All I need initially is a bit of digital i/o and some simple single-shot analogue reads and writes using DAQmx to control a USB-6225 or similar. Then I hope I'll learn to drive it and go on from there. Thanks.

[Norbert_B]

RB,

i want to clarify some of the statements done in this discussion thread.

First of all, it is possible to "purely" use the DAQmx driver to configure, start and interact with data acquisition devices from NI within your TestStand sequence.

Nevertheless, it is not suggested (and not documented).

The reason for not directly calling DAQmx via TestStand is usability, modularity of the application, hence re-usability and maintainability.

1. If you encapsulate the interface to your DAQ-device in a well written (and documented) module, the chance is high that you can reuse that code in some other projects, even if TestStand is not involved there.

2. TestStand is no programming language. It is a sequencer.

So you would have to transfer all mechanisms you would use in your programming language in order to interact with the DAQ-device into a collection of TestStand steps. You would have to store all parameters in the sequence. But remember: Those parameters are of no interest for the evaluation of the UUT. So why do you want to waste memory on that in your sequence execution?

3. The driver API is well documented for each programming language NI supports.

Depending on your personal preferences, you would use either C/C++ DLLs or .NET Assembly in TestStand to interact with DAQmx. Those functions are wrapped in the programming language API (CVI or C#/VB.NET) and that wrapper is documented. The basic driver functions encapsulated in the API are not documented. So you would have to dig in deeply to gather all mandatory information in order to create the TestStand steps.

4. Comparison to other vendors are always....dangerous.

Since i don't know about the special examples you state here, i cannot give anything useful to you except assumptions. So i assume that those vendors include high level functions in their drivers or, as already written by RMathews, you are already using a wrapper developed by those vendors.

NI does provide such a wrapper (DAQ Assistant), but it is only accessable using programming languages like LabVIEW, CVI or C# .NET, so not directly from TestStand.

High level functions (Get Measurement Value) are not available since the driver is the pure hardware interface and does not encapsulate "more logic than necessary".

Since TestStand is no programming language, that assistant does not provide a direct interface. You can file a product suggestion on this if you think that the DAQ Assistant should be accessable directly from TestStand.

So, the discussion is currently about perception of the driver (and its functionality). NI made the decision not to include high level API functions directly in the driver. This might be different for other vendors, but if i would have to use TestStand with some devices from other vendors than NI, i would always write custom modules to interact with those devices.....so for me, there would be no advantage of the driver supplying high level functions.

In fact, relying on high level functions is something i am feeling unsecure with. This is a personal reference.

If your personals reference are high level functions, simply use CVI or C# in order to encapsulate the DAQ Assistant.

hope this helps,

Norbert

[dotNet_to_LabW]

Hello Norbert,

I did not do any comparison. The last message was not from me.

Anyways, I was convienced with the reply posted by RMathews, but after seeing your reply I am confused again. What is true?

"..First of all, it is possible to "purely" use the DAQmx driver to configure, start and interact with data acquisition devices from NI within your TestStand sequence..."

or

"NI does provide such a wrapper (DAQ Assistant), but it is only accessable using programming languages like LabVIEW, CVI or C# .NET, so not directly from TestStand...Since TestStand is no programming language, that assistant does not provide a direct interface. You can file a product suggestion on this if you think that the DAQ Assistant should be accessable directly from TestStand..."

Now I am using a code wrapper in CVI, but am still interested in accessing direclty. Can you suggest me simply a dll file with the help of which it is possible. You can also read very first message in this forum where I explained the issue.

Ciao

RB

[Norbert_B]

RB,

if you have installed the textbased code support of DAQmx, you will get examples. There should be examples for C# as well....if you take a look into that code, every single line would have to be "transferred" to TestStand and rebuild using the .NET DAQmx assembly.

So, it is way easier to start with proper examples in a programming language rather than to reinvent the wheel by doing that transfer stuff. On a side node: i have never done so, so maybe there are pitfalls which are very annoying to identify and rework, so it is timesaving, more prudent (modular) using a "wrapper".

just my 5 cents,

Norbert

PS: Sorry about "misdirecting" my post

[RayFarmer]

that's the trouble when user's highjack a post (especially if that post has been solved). Much cleaner to start a new post everytime and add a link to the post you think is similar.

(that's my 5 cents)

[qwertyuiop1]

Wow, the power of collaboration, and the dedication and allround helpfulness of people amazes me sometimes. This is one of those times. Especially you Norbert B; this must have taken some time to think through and type out. Your essay is worthy of inclusion in the NI documentation somewhere, to satisfy people like me, new to TestStand. Thank you so much.

I apologise for being percieved as having hijacked a solved thread. I didn't (and still don't) see it that way.

For the current project, the tool of choice will be C# using Visual Studio Express. I expect it will be straightforward. Your assumptions are correct: these other vendors have written their own assemblies, which are intended to be called from a programming language such as CVI, LabView or C#.

So my answer after all is, it is *possible* to use TestStand directly but
- it's not easy
- it's not documented
- it's not easily maintainable
- it's not portable
- it's not easily re-usable
and all these are solved by modifying a few supplied examples and creating a wrapper I can call my own.



James L.

[dotNet_to_LabW]

I do not blame you James. At beginning even I thought the same way but after working with TestStand for around 6 months, I am convienced about using it for our all further tests. Fact is because it is different than programming language we are used to, that's why there is a level of inacceptence in the beginning. Moreover, it is not a "programming language".

- it's not easy  //It is so easy that it is easily understandable by testers/technicians and is the main reason why we are using it. Rather than teaching people a programming language, I give a small schooling of half a day and soon can hand over my work to tester.

- it's not documented //There is sufficient documentation available, but in start even I thought that documenataion was not sufficient. In my case reason was that I did not want read manuals. Its so much of work 🙂
- it's not easily maintainable // Till now I did not face problem with it. What exactly you mean by it?

- You can focus more on test than on programming, else you will need one more test program to test your test-program 🙂

About reusability, I do not tend to agree.

You can integrate dll of different languages. You just make test sequence which later can easily be sorted and used by a tester according to test requirement. I do not think it is a good solution to allow tester to either change your code and make her/him learn programming language or develop a GUI on your own to ease the tester.

I am not trying to change "tool of choice" for your current project, but try bringing more time with TestStand, you will understand the difference soon. After 3 years of your tes-project imagine a bug came in product, you have left company and someone else have to work on your code in C#....not so easy..By the way, I got nothing against C#..I was C# programmer for last 4 years 🙂

---