Cant execute sample Acq-IntClk (or indeed any NiDAQ using example)

[Tim Burgess]

Hi,
Have built pyrwi and the nidaq libraries following the instructions provided.

However, I cant get the Acq-IntClk example to run and it seems to crash python. (python.exe has encountered a problem and needs to close -etc)

My platform

• Windows XP 32bits
• Python 263
• MingW and friends
• NI USB 6211
• VMware Workstation 6 on top of Centos53
  

I have written a few lines of my own and am able to get simple string messages out eg:

Device name is:  Dev1\000
Status following reset:  0
Device Dev1 passed the Self Test
Product Category:  14643
Serial Number: 1458e44
Product Type:  USB-6211\000

but as soon as a pointer to anything other than a string is used - crash. I note that the strings are returned containing the C terminating null character too.

Interestingly running NI Max randomly between runs of my code and even executing continuous samples on NI Max whilst my code makes the above queries seems to work fine. The reset line stops NI Max in it''s tracks too. So I am confident I am communicating with the driver and it's effecting the hardware.

However, a few attempts at running Acq-IntClk (which crashes on the second line) will eventually cause what seems to be a driver crash, as NI Max ceases to operate and reports that something is going wrong.  The C experience in me is screaming pointer problems.

However in the length of time it's taken me to type this email, the driver seems to have returned to a working state and NI Max is happy again. The NI driver does seem to recover after each lock up - I don't need to restart Windows each time.

The line that dies in the sample is

    DAQmx.CreateAIVoltageChan(task,"Dev1/ai0:1","",\
            DAQmx.Val_Cfg_Default,-10.0,10.0,\
            DAQmx.Val_Volts,None)                       #Configure to read a voltage

Stepping over this line in the debugger immediatley results in a python crash message.

I am very new to pyrwi, nidaqmx, and SWIG.
However, I have considerable C experience and grasp pointers very well. I also have done 3 years of python - serial ports and gui applications chatting to custom machines.

Poking around in the .i files for SWIG and the resulting  wrapper is slowly making sense.
 
Daniel (or anyone) can you confirm that the lastest svn code results in an operable Acq-IntClk - and indeed all the other sample?

This will let me know if it's a problem at my end or not.

Thanks

-- 
Tim Burgess

[Daniel Rairigh]

Tim,

I will not have time to look into this more until Fri. I can tell you
that reporting C errors back up to Python through SWiG can be
difficult at times. I have tried to trap most errors, with this code:
/
**********************************************************************
* Convert DAQmx return codes to Exceptions

**********************************************************************/
%exception {
$action
if ( DAQmxFailed(result) ) { RaiseError(); SWIG_fail; }
}
%{
static void RaiseError() {
char errBuff[2048]={'\0'};
DAQmxGetExtendedErrorInfo(errBuff,2048);
SWIG_exception(SWIG_RuntimeError, errBuff);
fail:
return;
}
%}

However, any C error that slips past that will just crash the Python
interpreter.
I will try re-running the Acq-IntClk example this weekend.

Daniel

On Oct 27, 9:01 pm, Tim Burgess <t...@tbitc.com> wrote:
> Hi,
> Have built pyrwi and the nidaq libraries following the instructions provided.
> However, I cant get the Acq-IntClk example to run and it seems to crash python. (python.exe has encountered a problem and needs to close -etc)

> My platformWindows XP 32bitsPython 263MingW and friendsNI USB 6211VMware Workstation 6 on top of Centos53I have written a few lines of my own and am able to get simple string messages out eg:

[Tim Burgess]

Hi Daniel
see in yours

Daniel Rairigh wrote:
> Tim,
>
> I will not have time to look into this more until Fri.

No problems. Thanks. I just want to clarify that it does work and that
the problem is on my end only.

One thing that is bugging me overnight is that my python 263
installation is a windows precompiled binary. I don't know what tools
are used to build that binary.

To make the nidaq wrapper, I used the python263 source code for the
header (not worried about that) and the binary installer supplied
library to link Mingw (gcc) against.

This morning I have attempted to build a Mingw python binary and install
that - however python263 sources dont build with Mingw as supplied.
There needs to be some patching done - which I have yet to attempt,
because the patches only exist for python251.

I am wondering if a mismatch between the python windows binary supplied
library and the mingw/gcc generated library going to cause difficulty. I
can see that the symbols are being extracted from the python library in
the gcc build phase and I dont get any errors reported - so I guess I am
worrying about nothing. Or a change in calling conventions?

It's been a couple of days tinkering with this with only minor success -
so I guess I have started seeing ghosts. :-)

In your environment what python binary are you using?

> I can tell you
> that reporting C errors back up to Python through SWiG can be
> difficult at times. I have tried to trap most errors, with this code:
> /
> **********************************************************************
> * Convert DAQmx return codes to Exceptions
>
> **********************************************************************/
> %exception {
> $action
> if ( DAQmxFailed(result) ) { RaiseError(); SWIG_fail; }
> }
> %{
> static void RaiseError() {
> char errBuff[2048]={'\0'};
> DAQmxGetExtendedErrorInfo(errBuff,2048);
> SWIG_exception(SWIG_RuntimeError, errBuff);
> fail:
> return;
> }
> %}
>
> However, any C error that slips past that will just crash the Python
> interpreter.
>

I must say that each time I think about how to debug this I am left
wondering how it would be possible. Judging by the way the machine acts
following a crash, there is a several seconds pause in everything -
Windows stops responding and then away it goes again. It 'feels' like
the ni driver has been offended and it waits and then completely resets
itself and begins working again. This is seen in the national MAX and
for my code. So far reboots to return the nidaq code to a working state
have not been necessary, - perhaps the wrapper is whats dying...

> I will try re-running the Acq-IntClk example this weekend.
>

Perhaps if you could check all the examples - that would be nice to know
they are all confirmed working.

Would you be able to send or post, the wrapper and intermediate files
generated building the library (library files too please) A zip
containg the nidaqmx/build and nidaqmx/gcclib folders (or the entire
nidaqmx directory, would be real handy. So that I can test your working
build on my hardware.

I think a zip/tgz would be fairly small so I think would possibly be
able to email it to me directly.

Thanks again for your help

timb

--
Tim Burgess
TBITC Pty Ltd

[Daniel Rairigh]

I am using the Python 2.6.2 pre-compiled binary. From what I have read
Python 2.6 and up is using GCC to compile for windows. (was MSVC
before that, I think).

The best debugging method that I have found is to use WinPDB. Run up
close to the error and then step one statement at a time, decending
into all functions. At the very last Python call before the error
(usually not in your code, but in some sub-library) WinPDB will show
an exception in the exception pane right before everything crashes.
That is about the most effective method I have found. Second to that
is to add C code to the SWiG wrapper that calls
DAQmxGetExtendedErrorInfo(errBuff,2048); and sprintf it to the
screen.

Sorry this has taken a while for you to get running.

Daniel

On Oct 29, 12:03 am, Tim Burgess <t...@tbitc.com> wrote:
> Hi Daniel

[Daniel Rairigh]

Tim,

I just ran Acq-IntClk.py and DigitalOut.py with the latest SVN code.
They ran fine for me.

BTW, make sure you are using build.sh and not setup.py as listed in
the install.txt. setup.py is just a place holder it is not properly
configured yet.

Daniel