program locks on DAQmxBaseCreateTask

[JoeFriedchicken]

Hey Rolf,

We both had the same reaction at the same time, and I felt yours was less of an attack and more of a rebuke. Look at your post's timestamp and my post's timestamp. I'm a fast typist, but there's no way I could've formulated, typed, and formatted all that in under 120 seconds 😉 I generalized my statements to avoid singling out individuals, since such direct accusations are rarely constructive. I'm sorry for leaving it ambiguous.

I agree with Yawgmoth: let's return to the topic -- his problem 🙂 I still think Yanqele's views on LabVIEW for Linux are important, and I encourage him to start a new thread so we can explore them.

Joe

[Yawgmoth]

finally i had some time to work on that, and i solved the problem with a workaround: i made another program that just manages the NI USB-6501 and communicates with the main program through a named socket....

it only does initialization and input checking at the moment, but at least it works!!

[ematlis]

Hi-

I would like to report the same issue, using Fedora 10 and the NIDAQMXbase drivers (NIKALL 1.10 and nidaqmxbase 3.3) with either a USB-6009 or USB-6218.  I have tried two of the example codes; the acquireNScans.c in the ai examples directory, and the writeDigPort.c example in the dio examples directory.  With both examples, I see the following behavior:

either the code executes correctly, but with a ~1 second delay in the DAQmxBaseCreateTask step, or it hangs there and never finishes.

I have also noticed in the /var/log/messages statements to the affect that:

"sudo: mdns: Couldn't open nss_mdns configuration file /etc/nss_mdns.conf, using default."

I verified that this file does not exist.  I also tried creating a symbolic link to nss_nimdns.conf, but this did not help.  Perhaps there is a background daemon which needs to be running?

Please advise- this problem is making the NI hardware useless to me.

thank  you in advance,

eric

[JoeFriedchicken]

Hi Eric,

It's both good and troubling to hear your system has similar symptoms. How long have you waited before killing the process -- does it ever come back from DAQmxBaseCreateTeask()?

Yawgmoth's system is fairly customized, and after rebuilding the kernel and the NI modules, he reported better performance. It's possible that the Fedora kernel has also been tweaked enough to affect DAQmx Base. Since I haven't seen this problem in openSuSE 10.3 or RHEL 5 (which shares history with F6, and a much older kernel), I'm still leaning toward distro differences. Can you reproduce this problem in one of the NI-tested distributions for DAQmx Base 3.3? Those distros are: RHEL 4, RHEL 5, openSuSE 10.2 and openSuSE 10.3 [1].

Joe

[1] NI-DAQmx Base for Linux 3.3 readme

http://ftp.ni.com/support/softlib/multifunction_daq/nidaqmxbase/3.3/Linux/readme.txt

[ematlis]

I have waited over 2 minutes without anything.  I just started a new process with the "time" command;  this will tell me how long (if ever) it takes to come out.

As for changing the flavor of Linux, I was afraid you were going to say that.  If I install CentOS 5.4, will that suffice?

thanks,

eric

[JoeFriedchicken]

Heh, sorry for the pushback. It's not really feasible for my group to track all of the different Linux distros and their caveats, so we choose a small subset and test on those. I haven't seen this problem before in that subset, but if it's new or has slipped through our automated testing, I could then start investigating it.

If you want to use CentOS to try an reproduce the problem, please use 5.2 or 5.3. 5.4 won't work because it's base, RHEL 5.4, was released after DAQmx Base 3.3, so we haven't tested that OS. If you can reproduce the problem in CentOS, please let me know, and I can look into it. While not ideal, CentOS is a fairly good clone of RHEL.

Joe

[ematlis]

Joe-

I will try CentOS 5.3, thanks for the hint on that.

Just as another point of reference:  I compiled kernel version 2.6.28.10 from source.  The acquireNScans code works, but with some errors (note that I place a "hello" printf statement bracketing the CreateTask function call):

[matlis@turbine ai]$ ./acquireNScans
hello1
FATAL: Error inserting NiViPciK (/lib/modules/2.6.28.10/kernel/natinst/vxipnp/NiViPciK.ko): Operation not permitted
hello2
Acquired 3000 samples

Question: why is the NI driver trying to insert the NiViPciK.ko module?  It doesn't appear to be needed for the code to execute, and while I don't know what it's for exactly, the name seems to suggest it's needed for PCI devices.  Why load it if we are using USB code?  Could this be a source of the problem we are seeing?

The output from "dmesg" is below:


NiViPciK: no symbol version for _ZN22tMemBlockReferenceBase30assignExternalPointerNonSharedEmPv17tMemAddressOriginPl15tMemAccessFlagsS0_
NiViPciK: Unknown symbol _ZN22tMemBlockReferenceBase30assignExternalPointerNonSharedEmPv17tMemAddressOriginPl15tMemAccessFlagsS0_
NiViPciK: no symbol version for _ZN23tPIMMblockReferenceBase14allocateMemoryEm20tPIMMallocationFlagsm
NiViPciK: Unknown symbol _ZN23tPIMMblockReferenceBase14allocateMemoryEm20tPIMMallocationFlagsm
NiViPciK: no symbol version for _ZN22tMemBlockReferenceBase8allocateEmPl19tMemAllocationFlagsm
NiViPciK: Unknown symbol _ZN22tMemBlockReferenceBase8allocateEmPl19tMemAllocationFlagsm
NiViPciK: no symbol version for _ZN22tMemBlockReferenceBase30assignExternalPointerNonSharedEmPv17tMemAddressOriginPl15tMemAccessFlagsS0_
NiViPciK: Unknown symbol _ZN22tMemBlockReferenceBase30assignExternalPointerNonSharedEmPv17tMemAddressOriginPl15tMemAccessFlagsS0_
NiViPciK: no symbol version for _ZN23tPIMMblockReferenceBase14allocateMemoryEm20tPIMMallocationFlagsm
NiViPciK: Unknown symbol _ZN23tPIMMblockReferenceBase14allocateMemoryEm20tPIMMallocationFlagsm
NiViPciK: no symbol version for _ZN22tMemBlockReferenceBase8allocateEmPl19tMemAllocationFlagsm
NiViPciK: Unknown symbol _ZN22tMemBlockReferenceBase8allocateEmPl19tMemAllocationFlagsm

The NI modules that are actually loaded are shown below:

[matlis@turbine ai]$ lsmod | grep -i ni
niorbk                127764  0
nipalk               1409392  2 niorbk
nikal                  59156  2 nipalk

Thanks, and I will let you know what I find with the CentOS test.

eric

[mhoogend]

It seems a little odd that you are getting those particular symbols complained about with that list of kernel modules from NI already loaded.  I'm sure you ran updateNIDrivers at some point after compiling that kernel, but do you know for sure if it updated all your modules?  In particular NiViPciK.ko since it seems to be having problems?

I would expect that with the other modules loading you shouldn't be getting that error, now if it is a root cause for your USB problem I don't know.  You are correct that it is a module for using PCI devices.

[ematlis]

Joe-

I installed CentOS5.3.  The problem where the code hangs no longer occurs, however, I continue to notice a significant delay in the CreateTask function call.  I used the time command and determined it's exactly 2.00 seconds.  This seems unreasonable, particularly more more complicated acquisition and dio scenarios that may have many CreateTask calls.

Here is a snippet of how I get the time as applied to the acquireNScans.c code:

    #include <time.h>

   .

   .

   .

    time_t before, after;
  
    if((before=time(NULL))==(time_t)-1){
      fprintf(stderr,"Error: `time()'\n");
      return(-1);
    }
    DAQmxErrChk (DAQmxBaseCreateTask ("", &taskHandle));
    after=time(NULL);
    printf("Time used by CreateTask = %.2f sec's\n",difftime(after, before));

This is the output:

Time used by CreateTask = 2.00 sec's

Is a 2 second delay acceptable in your mind?

thanks,

eric

[ematlis]

Quick update-

sometimes the delay is 3.00 seconds.

eric