LV5.1/DAQ cpu resource question

[Ravi Narasimhan]

Hello all. I would like to request your suggestions on the following DAQ/LV
resource consumption problem.

I run LV 5.1 on W2000 notebook using a 16E-4 PCMCIA card with NI-DAQ. 300+MHz CPU
128MB RAM.

I would like to have a simple VI running continuously that reads 5 channels
at 1000 samples/sec, 100 samples at a time (about 100ms per acquisition.) Plan
is to do some simple arithmetic on each array and write global vars which can
be used by other VIs running in parallel with the acquistion VI. These VIs all
run slower than the DAQ. They update anywhere 0.5 one second intervals
to ten minute intervals and by just grabbing data, they do not talk to hardware.

I tried:

1) Circular buffered continuous data acquisition; consumes 90+% of the CPU due
to polling the AI Read VI. Other VIs cannot run or run very slowly. One of the
other VIs is a vendor-supplied instrument driver that uses VISA and takes about
40-50% of the CPU by itself. Got it down to <15% but there is still
a CPU usage conflict with the DAQ. The DAQ issue for the circ.
buffered acquisition is known, found tech support suggestions to try the
following:

2) Occurrence-driven VIs in example program database. CPU load goes way
down but the scan backlog behaves oddly. 1000 samples/sec and 100 samples
causes scan backlog to monotonically increase until it hits the buffer limit.
Other combinations of rates and sample sizes give about 100 scan backlog before
clearing. However, doing other processes with the CPU can cause the scan backlog
to jump up. ie. Hold down the left mouse on an LV pane, the backlog freezes, and
jumps to a larger number upon release. Backlog blips around the new value.
Obviously, changes in the signals take longer to clear the backlog
---

Then decided that if the dead time between acquisition and simple processing
were short compared to the 100ms acquisition time, that I could dispense with
buffers and just restart the DAQ but without doing AI Config over again.
ie. 100ms acquire, 10ms process, repeat. 10ms dead time is lost but not crucial

So,


3) Modified "Acquire N Scans.vi" from example programs so as to run
continuously. Put in occurrences, added a while loop around AI Start
and AI Read, and also a variable wait state (wait until multiple or simple wait
for x milliseconds) etc.

Never a scan backlog but CPU usage starts out low and
slowwwwwly creeps up, almost logarithmically until it reaches the mid 90% range.
VI eventually "freezes" The running VI indicator is still on but there
are no data transfers and no updates. VI must be aborted, closed, amd restarted.

Verified this on an NT4 system with a PCI version of the 16E series card so I
don't think it is the transfer rate difference between PCI and PCMCIA.

I chose this line of DAQ after trying
to sync multiple VIS with semaphores etc. to avoid multiple VIs calling
the DAQ hardware simultaneously. That was an even bigger brick wall. With this
approach, only one VI talks to the card and the others just read variables.

Since sound cards, video players, etc. can stream large amounts of data without
burdening the CPU unduly, I think that my plan to scan, process, write vars, and
repeat ought to work. I am, however, at a loss to understand why there is such
an issue with the CPU load and what I'm overlooking. Have been through what is currently
available on Deja and the NI databases along with talking with some good support
folks at NI.

Thanks in advance,

--- Ravi Narasimhan




--
Ravi Narasimhan
Dept. of Physics and Astronomy, UCLA
http://www.physics.ucla.edu/~oski
oski@physics.ucla.edu

[David Thomson]

Ravi Narasimhan wrote:
>
> Hello all. I would like to request your suggestions on the following DAQ/LV
> resource consumption problem.
>
> I run LV 5.1 on W2000 notebook using a 16E-4 PCMCIA card with NI-DAQ. 300+MHz CPU
> 128MB RAM.
>
> I would like to have a simple VI running continuously that reads 5 channels
> at 1000 samples/sec, 100 samples at a time (about 100ms per acquisition.)...
>
> 1) Circular buffered continuous data acquisition; consumes 90+% of the CPU due
> to polling the AI Read VI. Other VIs cannot run or run very slowly. One of the
> other VIs is a vendor-supplied instrument driver that uses VISA and takes about
> 40-50% of the CPU by itself. Got it down to <15% but there is still
> a CPU usage conflict with the DAQ. The DAQ issue for the circ.
> buffered acquisition is known, found tech support suggestions to try the
> following:
>

Ravi,
I would suggest going back to plan 1. I have used double buffered
data acquisition in a number of situations and managed to get to to work
successfully. I don't know which example you looked at, but I do recall
that some (all?) of NI's double-buffered examples succumb to the problem
you mention. The fix is quite easy. You need to add a Wait to the
acquisition loop. Calculate the wait time to be some fraction (50%,
80%?) of the acquisition loop time. The exact number can be tweaked
after you get it working. As you pointed out, the CPU hogging is done
by the Daq Read polling. Putting a Wait in frees the processor for
other tasks during the bulk of the acquisition time. As long as the
wait is small enough, your loop always gets back to reading the data in
time.

Good Luck,
Dave Thomson

-------------------------------------------------------------
David Thomson 303-499-1973 (voice and fax)
Original Code Consulting dthomson@originalcode.com
www.originalcode.com
National Instruments Alliance Program Member
-------------------------------------------------------------
Research Scientist 303-497-3470 (voice)
NOAA Aeronomy Laboratory 303-497-5373 (fax)
Boulder, Colorado dthomson@al.noaa.gov
-------------------------------------------------------------

[Ravi Narasimhan]

In article <3975BF44.4C948A2B@al.noaa.gov> David Thomson writes:
>Ravi Narasimhan wrote:

[ DAQ and CPU loadin]

>Ravi,
> I would suggest going back to plan 1. I have used double buffered
>data acquisition in a number of situations and managed to get to to work
>successfully. I don't know which example you looked at, but I do recall
>that some (all?) of NI's double-buffered examples succumb to the problem
>you mention. The fix is quite easy. You need to add a Wait to the
>acquisition loop.

I added variable wait states in the while-loop of the Continuous Acquistion
and Graph(buffered) example VI. I put the AI Read in a sequence structure and
made the next frame the wait. The scan backlog for all sampling rates and scan
lengths increased until the buffer size was reached at which point the VI aborted
with an error message.

This looks like a different kettle of fish than VISA. Going deeper into AI Read
shows that the ultimate call to the DAQ card is through a CIN. The CPU load appears
(could be wrong here) to be a result of something within the compiled CIN code. Once
the polling starts, buffers fill, backlogs are calculated, etc. With a VISA serial driver
that I once used, it was possible to go in and add some waits because all the code
was at the diagram level.

Calculate the wait time to be some fraction (50%,
>80%?) of the acquisition loop time. The exact number can be tweaked
>after you get it working. As you pointed out, the CPU hogging is done
>by the Daq Read polling. Putting a Wait in frees the processor for
>other tasks during the bulk of the acquisition time. As long as the
>wait is small enough, your loop always gets back to reading the data in
>time.

The problem I encountered above was slightly less sever with very short waits
(20ms or less.) The backlog took longer to get to maximum. The CPU load,
however, drops only as the length of the wait increases. At which point
the DAQ is the limiting factor.

--- Ravi

--
Ravi Narasimhan
Dept. of Physics and Astronomy, UCLA
http://www.physics.ucla.edu/~oski
oski@physics.ucla.edu

[Peter_Prinzen]

Hi,

your CPU-time-consumption problem can have different sources. First of all,
if you acquire the data in a loop, have you a small wait inside the loop,
i.e. 10 ms? Do you get the values continuously or in blocks of maybe 10 values?
(Get size of DAQ-Buffer without reading and if it is more than 10, read the
size currently in DAQ-buffer.)

Another reason could be the DAQ-card, did it use DMA?

hope that helps or shows a solution ...

Peter

--
Peter Prinzen, E-Mail: peter.prinzen@xon.de
XOn Software GmbH, Luisenstr. 43, 80333 München
Tel.: ++49 89 542716-0, Fax: ++49 89 542716-78

[Ravi Narasimhan]

In article <3975c423@newsgroups.ni.com> "Peter Prinzen" writes:
>
>Hi,
>
>your CPU-time-consumption problem can have different sources. First of all,
>if you acquire the data in a loop, have you a small wait inside the loop,

Yes. All my VIs are modifications of example programs. In case of the circularly
buffered acquisition, the AI Read is in a while loop. As I replied to Dave
Thompson, adding a wait state frees up CPU but the data backup in the buffers of the
DAQ card until it eventually overflows.

>i.e. 10 ms? Do you get the values continuously or in blocks of maybe 10 values?
>(Get size of DAQ-Buffer without reading and if it is more than 10, read the
>size currently in DAQ-buffer.)

I am getting 100 scans on 5 channels at
a sampling rate of 1000 samples/sec. So,
it is a smallish block of data.

>Another reason could be the DAQ-card, did it use DMA?

I am presently running a PCIMIO-16E-4 card on a PCMCIA bus. I tried the same
VIs on a desktop PC with a PCI version of the same card that uses DMA and had the
same problems come up.

>hope that helps or shows a solution ...

Thanks for the pointers,

--- Ravi

--
Ravi Narasimhan
Dept. of Physics and Astronomy, UCLA
http://www.physics.ucla.edu/~oski
oski@physics.ucla.edu

[Jeremy]

I agree that putting appropriate waits in the loop should help the problem. Incidentally, the PCMCIA cards do not support DMA (some hardware inconsistencies among chipsets, if I recall correctly).

[Jeremy]

Another important item to try:
Set up the priority (do get VI info, execution options) and put your acquisition VI in a different thread (data acquisition, for example) in addition to your option (1). In multi-thread mode on Windows, your acquisition should now be separated from your user interface.