DAQmxReadDigitalScalarU32 not in type library

[cborn]

DAQmxReadDigitalScalarU32 doesn't appear to be in the .tlb

I've managed to get the call working by adding the following declaration to a code module

Declare Function DAQmxReadDigitalScalarU32 Lib "nicaiu.dll" (ByVal taskHandle As Long, ByVal timeout As Double, ByRef Value As Long, ByRef reserved As Any) As Long

Is there a reason for it being left out of the type library?

Thanks,

David

[bilalD]

VB 6.0 does not support unsigned data types. If you use the unsigned version of the daqmx function and try and manipulate the returned value in VB 6.0, you might get some unexpected results.

This difference is described in the DAQmx C API visual basic 6.0 help under Start >> Programs >>National Instruments >> NI-DAQ.

The topic of interest is "Differences Between the NI-DAQmx C API and the NI-DAQmx Visual Basic 6.0 API"

[cborn]

Thanks Bilal,

As I'm only using 8 bits anyway, that won't be a problem for me!

I've added the digital read and write code to my ActiveX control, emulating the traditional API's functions to set the data direction register by setting the appropriate line specifications in the "tasks", which means applications which my OCX will be able to use the new system unchanged.

I had to add another declaration for writing:

Declare Function DAQmxWriteDigitalScalarU32 Lib "nicaiu.dll" (ByVal taskHandle As Long, ByVal AutoStart As Boolean, ByVal timeout As Double, ByVal Value As Long, ByRef reserved As Any) As Long

In addition I'm a little concerned at the overheads in setting up "tasks" (as a loing-time writer of multi-tasking operating systems the appropriation of that term grates on me!) in NIDAQmx, on my test system the first time a task is set up seems to take 10 seconds or more, thrashing away on the disk. Admittedly the test system is slow and under resourced (64MB RAM and 300MHz processor), but the idea is that if the application runs on that it will do much better on a production machine. The Traditional code runs fine on the older hardware, however.

Cheers,

David

[bilalD]

That does sound like an old machine. I doubt you would see similar behavior on a more recent machine.

But you still are concerned about this, one thing you would try is to load up the DAQmx DLLs are part of the app initialization. You could make a call to DAQmxCreateTask and call    DAQmxClearTask on the task handle. This would load up part of the DAQmx libraries in the app initialization part. This might reduce the disk i/o you see when everything is loaded at once you start with the i/o operation since part of the libraries will already be in memory.

DAQmx was basically a redo of Traditional DAQ. There are more libraries that need to be loaded in memory, but you should not notice decreased in I/O performance once everything is up and running. I would expect that you notice the initial disk I/O initially, but once everything loaded you should get the same performance  (if not better) as Trad. DAQ.

Hope this helps.