Linux Users
program locks on DAQmxBaseCreateTask
hello!!
we should integrate the NI USB-6501 in one of our products, so i installed the drivers and checked the samples, that runs fine.
the problem is that if i insert the code to manage the device in our sowftware, it locks on DAQmxBaseCreateTask... 
if i attach the debugger to see what's going on, this is the output of backtrace:
Program received signal SIGINT, Interrupt.
0xb7e13431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) backtrace
#0 0xb7e13431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#1 0xb7066e12 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#2 0xb7066d02 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#3 0xb7085fec in ThFreeSysUIThread () from /usr/local/lib/liblvrtdark.so.8.2
#4 0xb71936a2 in GetCurrentExecutingVIPath () from /usr/local/lib/liblvrtdark.so.8.2
#5 0xb7193e76 in GetCurrentExecutingVIPath () from /usr/local/lib/liblvrtdark.so.8.2
#6 0xb718d171 in ConfigExec () from /usr/local/lib/liblvrtdark.so.8.2
#7 0xb7197e1e in GetCurrentExecutingVIPath () from /usr/local/lib/liblvrtdark.so.8.2
#8 0xb712e83b in CallVIFromDll () from /usr/local/lib/liblvrtdark.so.8.2
#9 0xb7732469 in LV_DAQmxBaseCreateTask (taskName=0x811c6d8 "", taskHandle=0xadc02c08) at nidaqmxbaselv.c:1796
#10 0xb79a5aca in DAQmxBaseCreateTask () from /usr/local/lib/libnidaqmxbase.so.3
#11 0x080a59c6 in TVdsExtIO::InitIOCard (this=0xadc00018) at vds_ext_io.cpp:141
#12 0x080a58e3 in TVdsExtIO (this=0xadc00018, vds_ext_io_parms=0xaf16fac0) at vds_ext_io.cpp:119
#13 0x080a552f in vds_ext_io_main (ptr=0xaf16fac0) at vds_ext_io.cpp:75
#14 0x080fc0ce in SalFork (func=0x80a54ce <vds_ext_io_main(void*)>, ptr=0xaf16fac0) at linux/base.cpp:200
#15 0x08056672 in TVdsMain::StartModule (this=0x82cd138, i=3) at vds_main.cpp:2785
#16 0x08056f56 in TVdsMain::RestartModules (this=0x82cd138) at vds_main.cpp:3082
#17 0x0805988c in TVdsMain::ChkNewConfig (this=0x82cd138) at vds_main.cpp:4094
#18 0x08050a68 in TVdsMain::MainLoop (this=0x82cd138) at vds_main.cpp:609
#19 0x0804c53b in main (argc=1, argv=0xbfea5bb4) at vds.cpp:111
so, it seems that there is a problem with a mutex, but i have no clue about the way to solve it.....
these are the parts of the code that takes care of the initialization:
vds_ext_io.h #include <NIDAQmxBase.h>
/* ----------------------------------------------------------------------- */
/* - definition of object TVdsExtIO - */
/* ----------------------------------------------------------------------- */
class TVdsExtIO {
private:
TaskHandle Task;void InitIOCard();
void QuitIOCard();
public:
TVdsExtIO(TVdsExtIOParms* vds_ext_io_parms);
~TVdsExtIO();
};vds_ext_io.cpp
#include "vds_ext_io.h"
int32 error = 0;
#define DAQmxErrChk(functionCall) { if (DAQmxFailed(error = (functionCall))) { throw "Cannot init ExtIO module"; } }
/* ----------------------------------------------------------------------- */
/* - object TVdsExtIO - */
/* ----------------------------------------------------------------------- */
/* ----- constructor ----------------------------------------------------- */
TVdsExtIO::TVdsExtIO(TVdsExtIOParms* vds_ext_io_parms) {// more init instructions, removed for clarity
InitIOCard();
}/* ----- inizializzo la scheda di estensione i/o ------------------------- */
void TVdsExtIO::InitIOCard() {
syslog(LOG_INFO, "Init I/O card started...");
Task = 0;
char chan1[] = "Dev1/port0";
char chan2[] = "Dev1/port1";
char chan3[] = "Dev1/port2";
try {
// create digital input/output task and channel
DAQmxErrChk(DAQmxBaseCreateTask("", &Task));
syslog(LOG_DEBUG, "Task created...");
DAQmxErrChk(DAQmxBaseCreateDIChan(Task, chan1, "", DAQmx_Val_ChanForAllLines));
syslog(LOG_DEBUG, "Channel block 1 created...");
DAQmxErrChk(DAQmxBaseCreateDIChan(Task, chan2, "", DAQmx_Val_ChanForAllLines));
syslog(LOG_DEBUG, "Channel block 2 created...");
DAQmxErrChk(DAQmxBaseCreateDIChan(Task, chan3, "", DAQmx_Val_ChanForAllLines));
syslog(LOG_DEBUG, "Channel block 3 created...");
// start task (configure port)
DAQmxErrChk(DAQmxBaseStartTask(Task));
} catch (...) {
syslog(LOG_ERR, "Error during init of I/O card!!");
ModuleRun = false;
}
syslog(LOG_INFO, "Init I/O card completed successfully and task started!!");
}
as you may notice, i modified the definition of DAQmxErrChk to rise an exception, instead of jumping to a label as it was in the samples, but i don't think it the cause of the problem....
thanks a lot for any hint you may provide me!! 
i made some more tests with the code i posted yesterday, and i noticed some strange things:
- the DAQmxBaseCreateTask takes a long time to return (more or less 40 seconds)
- it looks for /etc/nss_mdns.conf file, that was missing
Jan 12 09:19:46 vds-dev ext_io[20063]: Starting ExtIO module...
Jan 12 09:19:46 vds-dev ext_io[20063]: Loop count not specified. Using default...
Jan 12 09:19:46 vds-dev ext_io[20063]: Init I/O card started...
Jan 12 09:21:05 vds-dev ext_io[20063]: mdns: Couldn't open nss_mdns configuration file /etc/nss_mdns.conf, using default.
Jan 12 09:21:25 vds-dev ext_io[20063]: Task created...
Jan 12 09:21:25 vds-dev ext_io[20063]: Channel blocks created...
Jan 12 09:21:25 vds-dev ext_io[20063]: Init I/O card completed successfully and task started!!
Jan 12 09:21:25 vds-dev ext_io[20063]: ExtIO object started successfully...
so i created a link
[alberto@vds-dev user]$ ls -ls /etc/nss_*
0 lrwxrwxrwx 1 root root 15 Jan 12 09:38 /etc/nss_mdns.conf -> nss_nimdns.conf
0 lrwxrwxrwx 1 root root 36 Nov 23 10:09 /etc/nss_nimdns.conf -> /etc/natinst/.nicore/nss_nimdns.conf
but it changed nothing (it still takes 40 seconds to init)
Jan 12 09:39:01 vds-dev ext_io[21086]: Starting ExtIO module...
Jan 12 09:39:01 vds-dev ext_io[21086]: Loop count not specified. Using default...
Jan 12 09:39:01 vds-dev ext_io[21086]: Init I/O card started...
Jan 12 09:40:41 vds-dev ext_io[21086]: Task created...
Jan 12 09:40:41 vds-dev ext_io[21086]: Channel blocks created...
Jan 12 09:40:41 vds-dev ext_io[21086]: Init I/O card completed successfully and task started!!
Jan 12 09:40:41 vds-dev ext_io[21086]: ExtIO object started successfully...
i have also tried to run the program with the debugger and stop it during the wait time, and it's the output of backtrace:
Program received signal SIGINT, Interrupt.
0xb754e431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) backtrace
#0 0xb754e431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#1 0xb7dc2fbb in __pthread_cond_wait (cond=0x8084744, mutex=0x8084774) at forward.c:138
#2 0xb7617e12 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#3 0xb7617d02 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#4 0xb7636fec in ThFreeSysUIThread () from /usr/local/lib/liblvrtdark.so.8.2
#5 0xb763600b in ThFreeSysUIThread () from /usr/local/lib/liblvrtdark.so.8.2
#6 0xb76e513e in WaitLVClientReady () from /usr/local/lib/liblvrtdark.so.8.2
#7 0xb76df6fa in ReserveEPDS () from /usr/local/lib/liblvrtdark.so.8.2
#8 0xb7ce33e7 in LV_DAQmxBaseCreateTask (taskName=0x8048fff "", taskHandle=0x8085a58) at nidaqmxbaselv.c:1770
#9 0xb7f40aca in DAQmxBaseCreateTask () from /usr/local/lib/libnidaqmxbase.so.3
#10 0x08048c20 in TExtIO::InitIOCard (this=0x8085a50) at ext_io.cpp:97
#11 0x08048b24 in TExtIO (this=0x8085a50, ext_io_parms=0xbfeab9ec) at ext_io.cpp:59
#12 0x08048a5e in main (argc=1, argv=0xbfeaba94) at ext_io.cpp:40
i have not tried to do the same with the sample code, but from the tests i've done, it takes more or less the same time for DAQmxBaseCreateTask to return.
thanks in advance for any further help you may provide me!!
EDIT (2 posts in a row are already more than enough 
)
i run examples/dio/readDigMultiplePorts sample program with the debugger too, to see if there are any differences on the function calls while the program is calling DAQmxBaseCreateTask, but it looks the same:
Program received signal SIGINT, Interrupt.
0xb7661431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
(gdb) backtrace
#0 0xb7661431 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#1 0xb7ed5fbb in __pthread_cond_wait (cond=0x8084744, mutex=0x8084774) at forward.c:138
#2 0xb7729e12 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#3 0xb7729d02 in EventLoggingLogUserBuffer () from /usr/local/lib/liblvrtdark.so.8.2
#4 0xb7748fec in ThFreeSysUIThread () from /usr/local/lib/liblvrtdark.so.8.2
#5 0xb774800b in ThFreeSysUIThread () from /usr/local/lib/liblvrtdark.so.8.2
#6 0xb77f713e in WaitLVClientReady () from /usr/local/lib/liblvrtdark.so.8.2
#7 0xb77f16fa in ReserveEPDS () from /usr/local/lib/liblvrtdark.so.8.2
#8 0xb7df63e7 in LV_DAQmxBaseCreateTask (taskName=0x8049139 "", taskHandle=0xbfa96d48) at nidaqmxbaselv.c:1770
#9 0xb7f3baca in DAQmxBaseCreateTask () from /usr/local/lib/libnidaqmxbase.so.3
#10 0x08048b66 in main (argc=1, argv=0xbfa97624) at readDigMultiplePorts.c:51
and, of course, it takes more or less the same time to complete.
Messaggio modificato da Yawgmoth
JoeFriedchicken ha scritto:
So even the straight-C example programs that install with DAQmx Base stall for 40 seconds when they go to create the task? That's very unusual and shouldn't be happening.
yes, it hangs for more or less 40 seconds on DAQmxBaseCreateTask too....
JoeFriedchicken ha scritto:
Do you also have LabVIEW? I'm curious if the LabVIEW examples are equally slow.
not yet... i'll set it up and check its behaviour...
thanks again for reply!!
the problem is that there are quite a lot of atypical aspects on my development system.... 
and i had no time to work on that the last days 'cos i have to fix some bugs on our software..... 
i will let you know as soon as i can restart testing... thanks a lot for help!!
i tried to look for the evaluation version of LabVIEW, but it seems it's not available for linux.... 
btw, i had to rebuild the kernel, and after that i rebuilt the ni driver too.... now the demo programs starts in more or less 10 seconds....
it seems to point to the kernel, which on one side it good 'cos it helps to realize where the problem is, but on the oether side i'm not sure i'm skilled enough to debug that at kernel level....
do you know of any kernel options that may impact on the driver??
I respond to this only:
"i tried to look for the evaluation version of LabVIEW, but it seems it's not available for linux.... "
My university has a site license which came with both the Linux and the Windows versions.
My university does not distribute the Linux version because it lacks any protection against license violation (which MAY be why N.I. does not distribute it either; this is a plausible, yet to be proven, conjecture).
By unique exception, because of my age and records, I have been allowed to give the Linux version a short try, and I swiftly returned it after finding out that beyond the protection it also lacks the most important tool required to build VI's.
Just open http://www.ni.com/labview/how_to_buy.htm , click Data Acquisition Functions and Wizards and enjoy 
not having wasted the time to download, had you found it.
Naturally, nor does it (LabVIEW Linux) support USB devices ( ni.com/info code rddqld )..
So, if you would have found a Linux demo version, you would just have added one or more or 
while my choice would be (shocked)
Jacques Goldberg, Prof.
