program locks on DAQmxBaseCreateTask

[JoeFriedchicken]

Hi Eric,

From a speed performance perspective, I don't think a 2-3 second delay is acceptable for creating a task in DAQmx Base. Indeed, DAQmx 8.0.1 typcially does the same in 5 ms on Linux.

But given that the code in DAQmx Base is cross-platform, I think a 2-3 second delay is expected. All of our driver logic and operations are done in LabVIEW, even in a C program [1], and so we trade speed in certain driver calls to gain cross-platform flexibility.

DAQmxBaseCreateTask() and DAQmxBaseClearTask() are typically called less frequently than the other functions, where users generally keep a task around for the life of the program and reuse it as they see fit. What use case do you have in mind that prompts heavy use of the Task() calls?

Joe

[1] Linux console session
$ ldd acquire1Scan
      linux-gate.so.1 =>  (0xffffe000)
      libnidaqmxbase.so.3 => /usr/local/lib/libnidaqmxbase.so.3 (0xb7f9f000)
      libc.so.6 => /lib/tls/libc.so.6 (0xb7e71000)
      libnidaqmxbaselv.so => /usr/local/lib/libnidaqmxbaselv.so (0xb7e69000)
      /lib/ld-linux.so.2 (0xb7fc6000)
      liblvrtdark.so.8.2 => /usr/local/lib/liblvrtdark.so.8.2 (0xb76e5000)
      libdl.so.2 => /lib/libdl.so.2 (0xb76e0000)
      libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb76ce000)
      libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb760f000)
      libm.so.6 => /lib/tls/libm.so.6 (0xb75ea000)
      libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75df000)

[ematlis]

We will be creating a code that switches from DO to AI many times (moving a stepper motor, then acquiring, then moving again etc).  I assumed this would require many instances of CreateTask.  As I haven't actually written the code yet, that's just an assumption.  Please let me know if I'm wrong about that.

If it's a one time call, I guess we can live with a 2-3 second delay.  But if we have to re-call that function for each instance of an AI or DO, then it would be a problem.

Another possible scenario is sending a DO and then quickly performing an AI (we will be triggering an event, which needs to be captured soon after it is triggered). 

eric

[JoeFriedchicken]

Each multi-function DAQ device has multiple subsystems that perform different operations. Our drivers allow more than one subsystem to be used at the same time, so it is possible to have an AI task running while a DO task is also running. The basic program architecture would look something like:

1) Create each task and configure its channels/timing/trigger
2) Start each task
3) Loop a-c
a) Read AI
b) Analyze (perhaps in a different thread)
c) Write DO
4) Stop and clear each task

But this is starting to get off topic. If you're interested in DAQ programming best practices, you may want to use the full ni.com DAQ forums [1] to ask more specific questions or call or email NI for one-on-one help.

It sounds like you're doing some kind of control application, and I'm a little concerned that you've chosen a USB product for the sensor and actuator IO. USB communication is not deterministic, and you won't be able to guarantee loop times for a control algorithm. PCI device operations, on the other hand, can be made deterministic and would be better suited for robust controllers.

Joe

[1] NI Multifunction DAQ Forums

http://forums.ni.com/ni/board?board.id=250

[ematlis]

Joe-

thanks for the suggestions.  Most our DAQ requirements are not going to be deterministic.  My only concern as I mentioned would be if we were incurring many of the 2-3 second delays required by the CreateTask function.

I'm interested, however, in the ability to do AI and DO at the same time.  Does that apply to nidaqmxbase code?  I thought that code was not thread safe.  Can you provide a code snippet of how to do it?

thanks,

eric

[JoeFriedchicken]

You can use all of the device's subsystems at the same time with DAQmx Base without writing a multi-threaded program. This is a faint distinction to make, but there are really two things happening here: the hardware is doing stuff, and the driver is doing stuff. While the hardware has no problem doing stuff in parallel, the driver does.

As long as every call to DAQmxBaseFunctionX() is made from the same thread, you'll satisfy the no-multithread condition, regardless of how many subsystems you address. If you want AI and DO, just merge the two examples you want into a single program, and run it 🙂

Joe

[ematlis]

Joe- I am seeing this error when I try to perform dio twice in a function that is contained in a subroutine (in a separate file):

DAQmxBase Error -200428: Value passed to the Task/Channels In control is invalid.

an outline of the code is below.  We have two files- the main file and the subroutine file.  In the main file, I have:

#define DAQmxErrChk(functionCall) { if(DAQmxFailed(error=(functionCall)) ) {goto Error; }}

int writeDigPort(TaskHandle taskhandle,int,int);  //This is the dio subroutine

int main(void) {

        TaskHandle taskHandleDO = 0;

        int direction ;
// Set Channel Numbers, filenames
        char chan[] = "Dev1/port1";
// Task parameters
        int32     error=0;   
        char errBuff[2048];

// Begin Program
    DAQmxErrChk (DAQmxBaseCreateTask ("",&taskHandleDO));
    DAQmxErrChk (DAQmxBaseCreateDOChan(taskHandleDO,chan,"",DAQmx_Val_ChanForAllLines));
    DAQmxErrChk (DAQmxBaseStartTask (taskHandleDO));
        direction = 1;
    DAQmxErrChk (writeDigPort (taskHandleDO,1,direction));  //This is the dio subroutine call
        usleep(1000000);
    direction = 0;
    DAQmxErrChk (writeDigPort (taskHandleDO,1,direction));

   .

   .

   .

In the subroutine file, I have:

#define DAQmxErrChk(functionCall) { if( DAQmxFailed(error=(functionCall)) ) { goto Error; } }
int writeDigPort(TaskHandle  taskHandleDO, int lineNum,int direction)
{ 

    int32       error = 0;
   char        errBuff[2048];
  uInt32      w_data[1];
   int32       written;

   if(direction == 0) {w_data[0]=0;} //set all channels to zero
   else {w_data[0]=lineNum;} //turn on selected channel
   DAQmxErrChk (DAQmxBaseWriteDigitalU32(taskHandleDO,1,1,10.0,DAQmx_Val_GroupByChannel,w_data,&written,NULL));

The subroutine is called twice by the main program.  The first time it works, the second time I get the error shown above.   I looked up the error number, but all I found was this:

http://digital.ni.com/public.nsf/allkb/7705D38D59EF562886256F79007E4B5A

which assumes labview is being used.

Any thoughts?

thanks,

eric

[JoeFriedchicken]

Hi Eric,

I would really like to continue troubleshooting your program, but not only are we getting off topic, we're moving toward an area where NI has a dedicated group of engineers for solving user applications (and to which I used to belong ;-). My role is driver development and I need to focus my time on those efforts. Please start a new thread either in main NI forums or contact National Instruments support.

Joe

[Braice]

Hello. I have a similar problem on a fresh opensuse 11.1 install and NI DAQmx base version 3.4.0

When I do a time on the example program ai/acquireNScans I obtain

real    0m30.599s
user    0m30.210s
sys    0m0.180s

I've added some debuggung information and it takes this time on the CreateTask function

Doing an strace on this program tells me that it hangs on some futex

I don't have labview installed on this computer

The hardware works just fine under windows.

If I can do any other tests, please tell me

Thanks

Brice

[jhsu_adsys]

Hello, I am having a very similar problem.  On my installation, NI DAQmxbase version 3.4.0 takes roughly 20 seconds to initialize.  Once task is created, everything seems to work well.

My configuration:

DAQmxbase 3.4.0

Ubuntu 9.04

Hardware used:  PCI-6733

I understand Ubuntu is not a supported Linux distribution.  This is an existing system that we are tryting to bring AO functionality to and the system behavior I had observed seems to be similar to problem discribed in this thread.  Please let me know if there are any progress made in resolving this issue.  Our customer is not entirely happy about this situation.  Leaving this unresolved, likely, we may be forced to replace AO hardware with other sourcing down the line.  Is it worth a while for me to try DAQmx 8.0.1?  Since it's Ubuntu, driver installation does require some "extra work".  I would rather not go down this path unless somebody think this is worth a while thing to try.

Thanks.

Jeff

[Braice]

Hello

I my case, I solved the problem by downgrading to opensuse 11.0 and installing NI DAQmx v8.0.1

Concerning the hardware it's an PCIe-6259

Regards