Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Demo VI and NI-DAQ example give different results

I need to acquire data inside a C program from
two analog signals using rotary encoder as an
external scan clock , and for this I plan to use
the NI-DAQ API .

To try things out, I used first the demo VI
'Acquire N Scans - ExtScanClk' in LabVIEW and
acquired 5900 samples for each channel. This is
the correct value. However, when I tested the
equivalent NI-DAQ example
SCANsingleBufExtScan_Eseries.c, the demo acquired
only around 850 samples for each channel. Am I
missing something obvious here?

The hardware/software used:

* AT MIO-16E2
* PC 486 66 MHz, 16 MB RAM, Win 95
* LabVIEW 4.0
* NI-DAQ 6.1
* Borland C++ 5.0

Aleksandar

P.S. Please CC reply to
JelenakA@AgResearch.cri.nz because I cannot
follow this
newsgroup on my news server.


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 1 of 4
(2,693 Views)
[My congratulations to National Instruments for setting up a publicly
available newsgroup server.]

Greetings!

I now realize that several copies of my post littered this newsgroup. My
sincere apologies! There had been some problems with my browser's cookie
settings and the Deja.com web site and I was not aware that several copies
of my post went out while I was fighting with the web cookies.

Here's the correct version of my post:

================================
I need to acquire data inside a C program from two analog signals using
rotary encoder as an external scan clock, and for this I plan to use the
NI-DAQ API .

To try things out, I used first the demo VI 'Acquire N Scans - ExtScanClk'
in LabVIEW and acquired 5900 samples for each channel. This is the correct
value. However, when I tested the equivalent NI-DAQ example
SCANsingleBufExtScan_Eseries.c, the demo acquired only around 850 samples
for each channel. Am I missing something obvious here?

The hardware/software used:

* AT MIO-16E2
* PC 486 66 MHz, 16 MB RAM, Win 95
* LabVIEW 4.0
* NI-DAQ 6.1
* Borland C++ 5.0
================================

Further to my original post, I experimented a little with the NI-DAQ demo
(compiled as a Windows console app) and found out that while the E2 card
needed the rotary encoder signal for data acquisition (no signal -- no new
samples) it did not use it for timing of scans. I fed a TTL signal from an
HP waveform generator on two frequencies, 2 and 6 kHz, as external scan
clock, and the acquisition time for 5900 samples was exactly the same. It
looked like the E2 card still used some internal scan clock.

I don't know where to look for errors. I did not quite expect to hit
problems with the NI-DAQ demo example. I checked the NI-DAQ functions used
in it; they all have correct arguments. From what I understand, the
DAQ_Config function handles declaration of external scan clock and its
source. This signal is fed to the PFI7 pin of an SCB-68 box, the default
pin according to DAQ_Config instructions. Since the appropriate LabVIEW
example VI works, there must be some other NI-DAQ function called in it
which obviously sets up the E2 card correctly.

I would really appreciate anyone offering any hint to possible solutions
here.

Aleksandar
0 Kudos
Message 2 of 4
(2,693 Views)
Hello Aleksandar,
I read your posting, and I might be missing a few details....

(1) SCANsingleBufExtScan_Eseries.c was written to acquire 100 data ponits
from each of the two channels that are listed as defaults in the example
program. Acquire N Scans - ExtScanClk.vi, on the other hand, defaults to
acquire 1000 scans from channel 0. The fact that you got different numbers
leads me to believe that you changed the defaults - to what values did you
change the following?
* SCANsingleBufExtScan_Eseries.c: ulCount, and the sizes of piBuffer and
pdVoltBuffer
* Acquire N Scans - ExtScanClk.vi: scans to acquire

(2) I assume you connected the same exact clock signal to PFI7/STARTSCAN for
both examples?

(3) How many channels of data did you acquire?

See, the SCANsingleBufExtScan_Eseries.c example defaults the "dSampleRate"
(this gets translated into iSampTB and uSampInt in the DAQ_Rate call. This
is known as "channel clock rate" in LV DAQ nomenclature) to 1000Hz. That
means, at the fastest, this C example will switch thru the channel list
every 1ms. If you have 2 channels, it will take 2msec to rotate thru the
channel list (equiv. to 500Hz). So, if you did indeed use the 2 and 6kHz
clocks for your scan clock, it will only pick up every 4th or 24th pulse.
When the first scan pulse comes in, the scan is started, but remember it
takes 2 msec to scan, so the scan clock pulses that come during that time
period are rejected. The basic idea is that this should hold:

1/(total required scan time) > (scan clock rate).


On the otherhand, the LV example sets the channel clock rate to the fastest
rate possible by the board. In your case, this would be 2usec. Even if you
did the same 2 channel scan, it would only take 4usec to scan thru (equiv.
to 250kHz), so any scan clock slower than that would work. Since 1/(4usec)
> 6kHz, this works.

So, the solution is to modify your C example so that the iSampTB and
uSampInt in the SCAN_Start call reflect a faster channel clock rate, of say,
2usec. Then you will see the same behavior.

I hope this helps. Please let me know if you have any further questions.


--

| Ken Sadahiro (Ken.Sadahiro@ni.com)
| Sr. Software Engineer, User Advocate
| Systems & Architectures: Applications Group
+----+-------------------------------------------
| National Instruments Corporation
| 11500-A North MoPac Expressway
| Austin, Texas 78759-3504 USA
| Tel: +1.512.683.8806
| Fax: +1.512.683.8641
| URL: http://www.ni.com/


Aleksandar Jelenak wrote in message
news:380A8F03.78F11C07@NOSPAMAgResearch.cri.nz...
> [My congratulations to National Instruments for setting up a publicly
> available newsgroup server.]
>
> Greetings!
>
> I now realize that several copies of my post littered this newsgroup. My
> sincere apologies! There had been some problems with my browser's cookie
> settings and the Deja.com web site and I was not aware that several copies
> of my post went out while I was fighting with the web cookies.
>
> Here's the correct version of my post:
>
> ================================
> I need to acquire data inside a C program from two analog signals using
> rotary encoder as an external scan clock, and for this I plan to use the
> NI-DAQ API .
>
> To try things out, I used first the demo VI 'Acquire N Scans - ExtScanClk'
> in LabVIEW and acquired 5900 samples for each channel. This is the correct
> value. However, when I tested the equivalent NI-DAQ example
> SCANsingleBufExtScan_Eseries.c, the demo acquired only around 850 samples
> for each channel. Am I missing something obvious here?
>
> The hardware/software used:
>
> * AT MIO-16E2
> * PC 486 66 MHz, 16 MB RAM, Win 95
> * LabVIEW 4.0
> * NI-DAQ 6.1
> * Borland C++ 5.0
> ================================
>
> Further to my original post, I experimented a little with the NI-DAQ demo
> (compiled as a Windows console app) and found out that while the E2 card
> needed the rotary encoder signal for data acquisition (no signal -- no new
> samples) it did not use it for timing of scans. I fed a TTL signal from an
> HP waveform generator on two frequencies, 2 and 6 kHz, as external scan
> clock, and the acquisition time for 5900 samples was exactly the same. It
> looked like the E2 card still used some internal scan clock.
>
> I don't know where to look for errors. I did not quite expect to hit
> problems with the NI-DAQ demo example. I checked the NI-DAQ functions used
> in it; they all have correct arguments. From what I understand, the
> DAQ_Config function handles declaration of external scan clock and its
> source. This signal is fed to the PFI7 pin of an SCB-68 box, the default
> pin according to DAQ_Config instructions. Since the appropriate LabVIEW
> example VI works, there must be some other NI-DAQ function called in it
> which obviously sets up the E2 card correctly.
>
> I would really appreciate anyone offering any hint to possible solutions
> here.
>
> Aleksandar
0 Kudos
Message 3 of 4
(2,693 Views)
Dear Ken,

> So, the solution is to modify your C example so that the iSampTB and
> uSampInt in the SCAN_Start call reflect a faster channel clock rate, of say,
> 2usec. Then you will see the same behavior.

That was it! Now the C example works OK. Gosh, it was so obvious and yet I
failed to notice it for so long.

Thanks very much,

Aleksandar
0 Kudos
Message 4 of 4
(2,693 Views)