Hello,
my basic problem is that i can't get a task to initialize in linux+nidaqmxbase+python.
here is a longer description, and i'm attaching various source code as well.
i'm trying to write a custom application using the nidaqmx drivers. I'd like easy gui development and quick development for all the high-level stuff, so i thought it made sense to use python, which has the added advantage of being fairly similar to matlab, which is what my coworkers already know. After some benchmarks, i found that python runs unacceptably slow on windows, but quite fast on linux.
So, i'm using the nidaqmxbase installed on mandriva.
When i write a C program, i can call the function DAQmxBaseCreateTask and confirm that the taskHandle i give it is initialized to a valid memory address. However, all of my attempts to do this in python seem to result in no errors being reported, but the taskHandle still being null. There are a couple examples of working python-nidaqmx code, but everyone seems to be doing this on windows for some reason. I suspect, based on the commented line in nidaqmxbase.h that the TaskHandle typedef is different in the linux version than in the windows version (it's a pointer to an unsigned long in linux, and the commented-out line is a typedef to an unsigned long) - but, who knows! basically my first attempt is just exactly the examples i found that people said were working for them using the windows nidaqmx drivers, as opposed to the linux nidaqmxbase.
my first attempt was to use python's ctypes library, which is standard in current versions of python. This makes it hard to assess where the failure is, but it's clear that the task isn't running properly.
my second attempt was to use pyrex, which lets you write in a mix of python and C, and then compiles itself to c code, which you can compile to a .so file and use as a python module. this allowed me to determine that the task handle was null, and in fact, if i try to dereference the task handle in the pyrex version, DAQmx catches the segfault and reports it.
at this point i thought that perhaps the problem was in the marshalling of pointers between python and the native libraries.
my third attempt was to write a library in pure c, which i can compile to a .so file and then either write a C executable that links against it, or use ctypes to import it into python. The frustrating thing is ... my C program gets an initialized taskHandle, but my python program does not! So now i know it's the exact same calls, and they're all being made from within a C library, so there is no marshalling of anything but integers between python and C ...
so!
something is changing when the call initiates from within python. I know that the ctypes library is generally felt to work correctly, and for that matter so is pyrex. I suspect that NIDAQmxBase drivers do something that's a little bit non-standard, and none of my python tools can handle it ...
but i'm wondering a few things..
-is there an NI programmer who reads these things who has some insight into the internal workings and can suggest why my daqmx library calls are failing, and how to work around it?
-has anyone else encountered this error and worked around it?
-has anyone made a succesful program using python on linux with nidaqmxbase, and if so, how did you accomplish the interop between python and daqmxbase ?
thanks!
