Simultaneous analog input/output on NI-6052E trouble

106 views
Skip to first unread message

labrat

unread,
Dec 10, 2007, 1:44:07 PM12/10/07
to Comedi: Linux Control and Measurement Device Interface
Goal:

Perform simultaneous, finite, buffered analog input/output.

I see people doing simultaneous AIO in kernel space with callbacks and
single point AO writes[1,2], but
(1) there are no callbacks in user space, and
(2) I don't have feedback, so I don't want the kernel in the loop.
Since I know my output beforehand, I want to write it to the card
before generation/aquisition begins.

Byran Cole seems to have gotten this working back in 2004 [3], but I
haven't found any explicit examples...

System:

Comedi: Comedi 0.7.75 (patched), Comedilib 0.8.1
Card: NI PCI 6052E
OS: Ubuntu 7.10
Kernel (from uname -a): 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12
GMT 2007 i686 GNU/Linux

Since Comedi didn't have support for simultaneous buffered commands, I
went digging in the NI DAQ-STC manual and found that I could trigger
the analog output start with the analog input start trigger
(AI_START1).
I made the adjustments to ni_mio_common.c listed in ni_mio_common-
patch.
I also applied (by hand) the patch suggested in [4], since I was
having the same problem (No lockups since patching).

Results:

Everything seems to work as expected 80% of the time, but ~ 20% of the
time simult_aio produces no analog output at all (verified with a
scope).
Using test.py, the failures seem to be randomly distributed (no more
likely to fail immediately after another failure), but I haven't done
any rigorous analysis.
I added some debugging 'printk's to ni_mio_common.c to check, and the
AO and AI subdevices are getting restarted after every program call,
so that's not it...

As far as I can tell, the registers should be identically set up for
each run, how can some attempts succeed while others fail?

I also tried inserting some waits (the usleeps) in simult_aio.c to
ensure that the problem wasn't some sort of timing issue, and still
got a 20% failure rate even with 1 second usleeps.

With my debugging printks, the output to dmesg for a single simult_aio
call is
"
[ 5795.131608] AO trigger on external signal
[ 5795.132755] trigger AI
[ 5795.133125] ni_event called
[ 5795.133135] Not an error, overflow, or eoa (0x4)
[ 5795.133807] ni_event called
[ 5795.133817] AI reset event
[ 5795.133819] resetting AI
[ 5795.133828] ni_event called
[ 5795.133830] AO reset event
[ 5795.133832] resetting AO
"

Any ideas?
Thanks,
Trevor


Contents of tar file:
simult_aio.c My simultaneous AIO test function
int16s_to_ascii_array.c Read int16 files and write the
corresponding ASCII array to stdout
stem_leaf.c Create an ASCII histogram of ASCII data
read in from stdin
test.py Test simult_aio using input channel 0 to
read output channel 0 (you must physically wire the two channels
together)
Makefile Run `make check` to compile the C source
and run test.py (after patching and recompiling comedi and
reconfiguring your board)
ni_mio_common-patch My alterations to ni_mio_common from
comedi-0.7.75
README This file.

References:
[1] 'comedi command structure', https://mail.comedi.org/pipermail/comedi/2001-May/001368.html
[2] 'simultaneous analog input/output',
https://mail.comedi.org/pipermail/comedi/2007-April/008446.html
[2] 'DMA on simultaneous AI & AO ?', http://osdir.com/ml/linux.comedi/2004-04/msg00127.html
[3] 'hard crash of kubuntu 7.10 on second run of simple program',
this group.

Frank Mori Hess

unread,
Dec 11, 2007, 9:37:20 PM12/11/07
to comed...@googlegroups.com
On Monday 10 December 2007 13:44, labrat wrote:
> Goal:
>
> Perform simultaneous, finite, buffered analog input/output.

I've done it before by routing the "ao start1" signal to a pfi output
channel, and making the ai command start trigger be the same pfi channel.

> Since Comedi didn't have support for simultaneous buffered commands, I
> went digging in the NI DAQ-STC manual and found that I could trigger
> the analog output start with the analog input start trigger
> (AI_START1).
> I made the adjustments to ni_mio_common.c listed in ni_mio_common-
> patch.

Where is ni_mio_common-patch? I'm guessing it adds support for TRIG_EXT as
the start source of an ao command? To do that requires fixing the
comedi's current scheme for output commands, which really is only suitable
for start source TRIG_INT. The new scheme would have to

1) call comedi_command()
2) preload output buffer
3) arm command (load data from buffer to hardware and enable start source.

--
Frank

labrat

unread,
Dec 12, 2007, 7:41:47 PM12/12/07
to Comedi: Linux Control and Measurement Device Interface
Frank,

Thanks for your response.

On Dec 11, 9:37 pm, Frank Mori Hess <fmh...@speakeasy.net> wrote:
> Where is ni_mio_common-patch? I'm guessing it adds support for TRIG_EXT as
> the start source of an ao command? To do that requires fixing the
> comedi's current scheme for output commands, which really is only suitable
> for start source TRIG_INT. The new scheme would have to
>
> 1) call comedi_command()
> 2) preload output buffer
> 3) arm command (load data from buffer to hardware and enable start source.

Oops, must have gotten confused attaching the tarball.

This is indeed what I do.
Works most of the time, and I have no idea why it should be work fail
randomly 20% of the time.
Any hints/leads appreciated.

Hmm, how do you attach files anyway...
Ah, `Files`. tricky tricky ;)
Alrighty, should all be in this tarball :

http://groups.google.com/group/comedi_list/web/simultaneous_AIO-0.1.tar.gz

Thanks,
Trevor

labrat

unread,
Jan 10, 2008, 8:40:16 AM1/10/08
to Comedi: Linux Control and Measurement Device Interface
For those who are curious, my current workaround is to T off one of my
output lines send one branch where I want the output and send the
other back into a spare input line.
After an attempted acquisition, I fit a line to the [output, input]
data, and look for slopes near 1.
If the slope is less than .95, I throw out that run and repeat.
This workaround fails if your scan changes the output by less than
your signal noise, but then it really doesn't matter if the output
worked or not ;).
Fairly ugly, but it gets the data in :p.

I'm still interested in following up any ideas people have about where
the failures come from...

Thanks,
Trevor
Reply all
Reply to author
Forward
0 new messages