Synchronize hardware timed buffered counter acquisition with buffered analog input acquisition

LV7.1
DAQmx
PCI-6036E
SC-2345
Windows 2000
Greetings.
I am simply trying to synchronize AI readings with readings from one Counter.
I am trying to perform buffered analog input synchronized with buffered counter acquisition.
I'd like the AI acquistion to trigger the Counter acquistion.
I'm currently setting the Sample Clock Source for the CI Cnt Edges Task to "Dev1/ai/SampleClock" but when I try and set the source for the "DAQmx Trigger" I can't seem to select one that works. I assumed that the source should be the "Dev1/ai/StartTrigger" but that produces and error as does selecting any of the PFI's.
I'm new to DAQmx and didn't have any luck with the examples or what's been previously posted.
Thanks for your help.
Attachments:
Initialization.jpg ‏84 KB

Gentlemen-
All of your initial help was great. I had some noise on my counter lines so switched from an E-Series card to a PCI-6259 M-series card in order to use the counter digital filters.
Now I can't get a corellated buffered counter and buffered analog input acquistion to work. This same code worked fine on an E-series card but it doesn't on the M-series.
I verified that the source and gate of the counter are working properly using the test panel and a external function generator.
But when I run the attached code I get no data out of the "Counter 1D U32 NSamples", only an error saying that the timeout of the function was reached and no count data became available. Am I missing the specification of a another clock or something?
The counters also work fine using the M-series example code "Count Digital Events (M-Series DAQmx) but this is not a buffered acquisition.
Any help would be greatly appreciated.
Steve
Attachments:
Sample_Code.jpg ‏136 KB

Similar Messages

Synchronizing two counter frequency inputs with multiple analog inputs

Hello all,
I'm fairly new to LabVIEW and I'm trying to collect data from multiple sources with synchronized timing on the acquisition but I'm having trouble figuring it out. My problem is that I've got two counter frequency inputs, one optical tachometer reading one pulse per revolution, and a max machinery flow meter with a k factor of 12000. I can't seem to figure out how to sync the timing with my multiple analog inputs. I've been attempting to get the tachometer to sync with the analog inputs first by following the example linked here. (https://decibel.ni.com/content/docs/DOC-10785) So far each time I run it I either get a timeout error on the DAQmx read or a "Multiple sample clock pulses were detected" error (see attached image). It seems if I slow the sampling rate way down to say 10 hz and ensure that the tachometer signal is over 800-1000 RPM (13-17 Hz) before starting the VI then the program will run without errors until the RPM drops below that threshold then the "Multiple sample clock pulses" error occurs. The code is attached below.
Does anyone know of a more effective way of syncing counter frequency inputs with analog inputs? I'd like to have a VI that can show 0 RPM (and eventually 0 flow as well, but I think I need to figure out the timing of one counter before I add another as it seems I can't have two counters in the same task). Any help on this would be greatly appreciated.
LabVIEW version 13.0
cDAQ-9178 Chassis with NI 9401 for the two counter inputs and NI 9205 for the analog inputs.
Thanks!
Richard
Solved!
Go to Solution.
Attachments:
SimpleDAQ.vi ‏44 KB
LV_Error.JPG ‏31 KB

Maybe third times the charm?
So I've finally got a good handle on why the VI is having problems at low RPM though I'm somewhat embarassed how long it took me to do that
Because I have the counter time synced to my Analog input task if it doesn't see at least two pulses between the two clock pulses set by the analog input task I get the -201314 "Multiple sample clock pulses" error. This seems fine at first as it just sets a minimum RPM that I can measure and it's well below the area I'm interested in so no problems there. I tried a simple error handler that would clear the error when it happend assuming the loop would keep iterating until the RPM went above that minimum at which point I would get a signal again. This is not the case, the read function just continues to spit out the -201314 error even after the RPM is back in the readable range. So then I tried adding two case structures so that when the error occured it would stop the task, clear the error, and then start the task again on the next loop iteration (Code Attached). This also doesn't work as the error shows up again on the stop task and then AGAIN on the start task on the next loop iteration. It seems this error is not actually being cleared and once it happens it stays with the task regardless of what the error cluster is carrying.
Anyone have any ideas? The only solution I can think of is to just clear all tasks and recreate them each loop iteration until the RPM is readable again but that strikes me as a horribly clunky solution.
Richard
Attachments:
SimpleDAQ_1_Start Stop.vi ‏48 KB

How to use counter output pulses to trigger analog input?

Hello all,
I hope the kind people using this forum can help me, a lowly beginner LV programmer! I have been attempting to create a VI that produces a user defined number of TTL pulses, separated by every n seconds. Each TTL would be outputted to a stimulator, which in turn generates its own TTL. Using the stimulator-generated TTL, I would like to trigger finite analog data acquisition (e.g. for every TTL, trigger the collection of a data sweep that contains 4000 samples (collected at 4000 Hz), with 1000 samples collected pre-trigger. I would like to also be able to see each data sweep as it is triggered on a chart. As I understand things (lots of online/book/forum reading), I should be using the counter output to generate my TTL pulses, and syncing each counter produced TTL with analog input, as well as using a reference trigger. Also, the AI part should be started first, so that I don' t miss any counter outputs. If it matters, I also need to use one of the AI channels to acquire the TTL, so I can see my stimulator-induced responses to the stimulator in time.
I am able to generate the TTL pulses from the counter output, but I am having a problem with the AI part. I am unsure how to sync the counter output with AI. Also, since I need to acquire pre-trigger samples, I would be needing to acquire samples continuously, but when I set 'continuous samples' on daqmx timing, the VI doesn't work (hence why's its set to 'finite samples').
I hope someone out there can help, as I have been at this for what seems ages, with limited success. I am using a USB-6259 and LabView v8.2. Thanks!
Attachments:
RC001 v_1.vi ‏49 KB

Hello,
Due to the fact that analog tasks themselves are not retriggerable, a
pulse train produced by a counter is always used as the sample clock
for the analog input task in order to recreate a retriggerable effect
for analog input. This can be done by creating a finite pulse train set
to retriggerable using the DAQmx Trigger Property Node, or the pulse
train could be continuous and just be gated by another signal. Neither
of these methods can be properly applied in hardware to create a
retriggerable reference trigger. You can however implement something
similar in software by just stopping and restarting your reference
triggered analog input task within a loop. There will be some delay
between when the task is stopped and restarted, as these events require
software intervention, but if there is enough time between when each
trigger signal is generated, there should not be any noticeable delay
or missed samples.
I have attached an example of this!
Mark B
===If this fixes your problem, mark as solution!===
Attachments:
RC001 v_1mod.vi ‏25 KB

Time measurement between counter output my device and analog input

Hello!
I'm trying to measure the time to generate a digital pulse train on the counter output, that goes to a frequency converter that controls a motor. So I think it'd be the best way to wire the output of the frequency converter with an analogue input and make a timestamp before I generate the pulse and a timestamp when I recognize the singal, but I think that wouldn't be a serious measurement ?
What's the best way to measure the time?
kind regards peter

hi there
well, there a several ways to do this. the problem with the software - timestamps is the minimal resolution of 1ms. i'd suggest:
- wire a copy of the digital pulse train to an analog input channel
- wire a copy of the frequency converter to another analog input channel
- create an analog input task with the two channels (the sampling rate defines the timing resolution,make sure to acquire enough samples to see the response signal)
- start this task
- send the digital pulse train
to optimize your acquisition you can use another copy of the digital pulse train as a start trigger for your analog acquisition.
-> then you'll see the digital pulse train on one of the analog channels and the frequency output on the other one. both channels have the same time axis with a resolution defined by your sampling rate (~us depending on your hardware). then you can analyze the data.
search the example finder for examples of how to create tasks and triggers.
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

Please help with C code to synchronize counter output to analog input

Hi All,
I am using NI DAQ USB-6353 with text-based C code to control it. I would like to send a continuous pulse train from the DAQ to pulse a power supply, which then activates an electron beam producing current to be read by the analog input port of the same DAQ. I would like to keep only the analog samples during the pulse peak and samples of a couple pulse widths right after. I am successfully to generate a pulse train using the sampled clock from a counter output channel, but fail to use the same clock to synchronize the pulse train with the analog input. DAQmxReadAnalogF64 is not called by the static function EveryNCallback set for the analog input task. Am I doing something wrong with the following codes? It would be great if it turns out only I am using the wrong sampled clock name of the counter ("dev1/PFI8") for the analog input. Or is something more fundamental that a counter cannot be sync. with an analog input?
Would someone be able to send me a link to an example in C or C++ or visual basic showing how to synchronize a buffered sample clocked digital pulse train from a counter output channel to an analog input? To simplify the post, the below codes do not include the static functions EveryNCallback and DoneCallBack, but I can send them if needed.
Many thanks in advance for your help,
Thuc Bui
//setting operation parameters
double initDelay = 0.0, freq = 10;
double dutyCycle = 0.0001;           //thus pulse width is 10 microsec
unsigned highTicks = 4;   //per period
unsigned numSamplesPerPeriod = highTicks / dutyCycle; //40000 samples/period
unsigned lowTicks = numSamplesPerPeriod - highTicks;      //per period
unsigned sampleRate = 2*numSamplesPerPeriod*freq;       //800000 samples/s
//create counter
TaskHandle counterTask;
int errCode = DAQmxCreateTask("", & counterTask);
errCode = DAQmxCreateCOPulseChanFreq(counterTask, "dev1/ctr0", "",
                                 DAQmx_Val_Hz, DAQmx_Val_Low,
                                 initDelay, freq, dutyCycle);
errCode = DAQmxCfgSampClkTiming(counterTask, "dev1/PFI8", sampleRate, DAQmx_Val_Rising,
                           DAQmx_Val_ContSamp, numSamplesPerPeriod);
//create analog input
TaskHandle aiTask;
double minVolt = 0.0, maxVolt = 1.0;
errCode = DAQmxCreateAIVoltageChan(aiTask, "dev1/ai0", "", DAQmx_Val_Diff,
                                 minVolt, maxVolt, DAQmx_Val_Volts, "");
unsigned bufferSize = 10* numSamplesPerPeriod;
errCode = DAQmxSetBufInputBufSize(aiTask, bufferSize);
errCode = DAQmxCfgSampClkTiming(aiTask, "dev1/PFI8", sampleRate, DAQmx_Val_Rising, DAQmx_Val_ContSamp, numSamplesPerPeriod);
errCode = DAQmxRegisterEveryNSamplesEvent(aiTask, DAQmx_Val_Acquired_Into_Buffer,
                                        numSamplesPerPeriod, 0, EveryNCallback, 0);
errCode = DAQmxRegisterDoneEvent(aiTask, 0, DoneCallBack, 0)
//start aiTask first
errCode = DAQmxStartTask(aiTask);
//then counterTask
errCode = DAQmxStartTask(counterTask);

Hi Xavier,
Thank you very much for getting back to me. I really appreciate it. I followed your advice with the option 2 and simplified my code by using one of the NI C example templates to generate the below codes (also attached). I was able to see the pulses generated with an oscilloscope, and on the same oscilloscope I could see the ouput pulses of the electron beam probe. Unfortunately, the below code via DAQmxReadAnalogF64 reports of no data read from the probe and finally times out. Below is the error message given by this function. I did check the connection of the analog input wires to make sure they were connected to pin 1 (A0+) and 2 (A0-) because I was using the terminal configuration DAQmx_Val_Diff. Do you see any obvious errors I have made in my codes?
Thanks a lot for your help,
Thuc Bui
Task started, waiting for trigger...
Acquired 0 analog samples DAQmx Error: Some or all of the samples requested have not yet been acquired.
To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0
Task Name: _unnamedTask<1>
Status Code: -200284
End of program, press Enter key to quit
********************** C Code **************************************************
#include <stdio.h>
#include "NIDAQmx.h"
#include <math.h>
#define DAQmxErrChk(functionCall) { if( DAQmxFailed(error=(functionCall)) ) { goto Error; } }
int main(void) {
int32 error = 0;
char errBuff[2048]={'\0'};
TaskHandle taskHandleDig=0;
TaskHandle taskHandleAna=0;
double  timeout=10;
double minVol = -1.0, maxVol = 1.0;
double initDelay = 0.0;
double freq = 10.0;
double pulseWidth = 1.0e-5; //10us
double dutyCycle = pulseWidth * freq;
unsigned hiTicks = 4;
double sampleRate = hiTicks/pulseWidth; //samples/s
unsigned lowTicks = ceil(sampleRate/freq) - hiTicks;
unsigned nSpPeriod = hiTicks + lowTicks;
unsigned numPulses = 1;
unsigned nSpCh = numPulses*nSpPeriod;
double sampleRate2 = ceil(2.0*sampleRate);
unsigned sampleMode = DAQmx_Val_FiniteSamps;
/*********************************************/ /*/ DAQmx Configure Code /*********************************************/
DAQmxErrChk(DAQmxCreateTask("", &taskHandleDig)); DAQmxErrChk(DAQmxCreateTask("", &taskHandleAna));
DAQmxErrChk(DAQmxCreateAIVoltageChan(taskHandleAna, "Dev2/ai0", "", DAQmx_Val_Diff, minVol, maxVol, DAQmx_Val_Volts, ""));
DAQmxErrChk(DAQmxCfgSampClkTiming(taskHandleAna, "/Dev2/Ctr0InternalOutput", sampleRate2, DAQmx_Val_Rising, sampleMode, nSpCh));
DAQmxErrChk(DAQmxCreateCOPulseChanFreq(taskHandleDig, "Dev2/ctr0", "", DAQmx_Val_Hz, DAQmx_Val_Low, initDelay, freq, dutyCycle));
DAQmxErrChk(DAQmxCfgSampClkTiming(taskHandleDig, "/Dev2/PFI12", sampleRate2, DAQmx_Val_Rising, sampleMode, nSpCh));
unsigned bufferSize = nSpCh;
DAQmxErrChk(DAQmxSetBufInputBufSize(taskHandleAna, bufferSize));
DAQmxErrChk(DAQmxSetBufOutputBufSize(taskHandleDig, bufferSize));
/*********************************************/ /*/ DAQmx Write Code /*********************************************/
DAQmxErrChk(DAQmxWriteCtrTicksScalar(taskHandleDig, 0, timeout, hiTicks, lowTicks, NULL));
/*********************************************/ /*/ DAQmx Start Code /*********************************************/
DAQmxErrChk(DAQmxStartTask(taskHandleAna)); DAQmxErrChk(DAQmxStartTask(taskHandleDig));
printf("Task started, waiting for trigger...\n");
/*********************************************/ /*/ DAQmx Read Code /*********************************************/
double* dataAna = new double[nSpCh];
int32 numReadAna = 0;
int errCode = DAQmxReadAnalogF64(taskHandleAna, -1, timeout, DAQmx_Val_GroupByChannel, dataAna, nSpCh, &numReadAna, NULL);
printf("Acquired %d analog samples\n",numReadAna);
if (numReadAna) {
    unsigned nPts = (numReadAna < hiTicks)? numReadAna : hiTicks;
   for (unsigned n = 0; n < nPts; ++n) {
         printf("%6.3f ", dataAna[n]);
    printf("\n");
delete [] dataAna;
DAQmxErrChk(errCode);
Error:
if( DAQmxFailed(error) )   DAQmxGetExtendedErrorInfo(errBuff,2048);
if( taskHandleDig!=0 && taskHandleAna!=0 ) {
/*********************************************/   /*/ DAQmx Stop Code   /*********************************************/
    DAQmxStopTask(taskHandleDig);
    DAQmxClearTask(taskHandleDig);
    DAQmxStopTask(taskHandleAna);
    DAQmxClearTask(taskHandleAna);
if( DAQmxFailed(error) )   printf("DAQmx Error: %s\n",errBuff);
printf("End of program, press Enter key to quit\n");
getchar();
return 0;
Attachments:
Correlated DIO AI_Sample_Clock Dig Start.c ‏6 KB

Scan rate using hardware timing.

How can I set the scan rate accurately to 1000 Hz using hardware timing.

Wire 1000.00 to the Scan Rate input of the AI Start VI. That will set up the scan clock on the DAQ board to run at 1000 Hz. Note that it will only work on NI DAQ boards.
Daniel L. Press
PrimeTest Corp.
www.primetest.com

DAQmx Error: Non-buffered hardware-timed operations are not supported for this d evice and Channel Type.

Hello,
I am new to NI and to data acuasition cards in general. I am trying to put an application togather that would play large audio file using NI9263.
And i am getting the following error.
DAQmx Error: Non-buffered hardware-timed operations are not supported for this device and Channel Type.
Status Code: -201025
Does my hardware support buffering ?
can i use the EveryNSamplesCallbackAO function ?
Any sample code, will be helpful at this time. Thanks.

Hi yma200,
Are you using a USB 9263? If so, this might be of help:
http://digital.ni.com/public.nsf/allkb/EC1968728E660B288625780700570D06?OpenDocument
If it doesn't help, can you please post the code that you have that is causing your error?
Regards,
Bogdan Buricea
Applications Engineer
National Instruments

How do I use the buffered counting mode at a fixed frequency?

Hi-
   I'm using a PCI-6259 M-series board with the Nidaq MX
drivers in Labview 7. I am trying to use one counter to do
buffered edge counting (eg. count how many pulses appear on one input
in 400 successive time bins of 10 uS each following a digital start
pulse). That is, my inputs are:
     Start Pulse (from experiment)
     Count Pulse (from a photomultiplier tube in the experiment)
And I want to know:
    # of pulses from 0 to 10 uS after the Start Pulse
    # of pulses from 11 to 20 uS after the Start
Pulse (or, equally good, # of pulses from 0 to 20 uS....I can
subtract later)
    # of pulses from 3991 to 4000 uS after the Start Pulse (or, # of pulses from 0 to 4000 uS...same thing)
   The Count Digital Events-Buffered-Finite-Ext Clk.vi sample
appears to do half of this. I can set this up CTR0 with the Count
pulse (and possibly add the start pulse as an Arm Start....I can't use
a Start Trigger, right?). However, I need to generate a Sample
Clock Source at 100 kHz (to trigger the card to buffer the counter
value and start counting in the next bin). So, I tried to set up
CTR1 along the lines of Gen Dig Pulse Train-Finite-Dig Start.vi for
generating a finite pulse train starting on a digital trigger, and
connecting the output from CTR1 to the Sample Clock Source on
CTR0. However, I get an error -50103 saying the specified
resource is reserved if I do both at the same time. But, I can't
see any resource conflicts...the pulse generation on CTR1 works fine
alone, as well as the buffered counting on CTR0, and all the PFI pins
are different. Is there some reason I can't use both counters at
the same time?
I think I can use the FREQOUT pin on the card to generate a Sample
Clock Source at 100 kHz, since I think this is independent of CTR0
& CTR1. However, I can't trigger the FREQOUT to always start
when I get a Start Pulse (as I can if I trigger a Digital Pulse Train
to start on a digital trigger...or can I?)...so my bins will move
randomly by up to 10 uS.
   This is an unrelated topic, but is there a discussion of
the relationship between the terminology in the manuals describing the
cards (SOURCE, GATE, OUTPUT terminals) and the terminology in NidaqMX
(Source Clock/SrcClk.Source, CI.CountEdges.Term, CO.Pulse.Term)?
Eg. is CTR0.GATE always the same thing as SrcClk.Source, or does it
depend on the mode of operation? If the M-series hardware manual
says to connect something to the SOURCE input, how do I assign an
alternate PFI pin to that SOURCE input in Labview? Does it depend
on the counter type, or is it always the same?

Dave,
Hi, you brought up several questions / issues -- let me see if I can help with some of them:
   I can set this up CTR0 with the Count pulse (and possibly add the start pulse as an Arm Start....I can't use a Start Trigger, right?).
Yes, you could set up this way. Also, as far as I know you're also correct that you need to configure for an "Arm Start" trigger using the DAQmx Trigger property node. The "Arm Start" trigger is used for counter input (measurement) apps while the regular "Start Trigger" can be used for counter output (pulse generation) tasks. I don't think I've experimented with recent versions of DAQmx though so it may have changed in 7.4 or 7.5
...I tried to set up CTR1 along the lines of Gen Dig Pulse Train-Finite-Dig Start.vi for generating a finite pulse train starting on a digital trigger, and connecting the output from CTR1 to the Sample Clock Source on CTR0. However, I get an error -50103 saying the specified resource is reserved if I do both at the same time
I highlighted the problem -- the FINITE pulse train. DAQmx uses CTR0 as a "helper" when you generate a finite pulse train on CTR1. It would generate a single pulse whose width corresponds to the exact amount of time needed for CTR1 to generate its specified # of pulses.
For your specific app, I think you could generate a triggered continuous pulse train with CTR1 -- this wouldn't need to use CTR0 as a helper.  The Start Pulse would arm CTR0 at the same instant that CTR1 is started.   If you set up CTR0 to acquire on the trailing edge of CTR1's pulses, then you'll get the time bins you want.
A final slight mod would be to setup CTR0 for measuring buffered periods (set units == "Ticks") instead of counting edges. In that mode, you wouldn't have to do the subtraction at the end.
   This is an unrelated topic, but is there a discussion of the relationship between the terminology in the manuals describing the cards (SOURCE, GATE, OUTPUT terminals) and the terminology in NidaqMX (Source Clock/SrcClk.Source, CI.CountEdges.Term, CO.Pulse.Term)? Eg. is CTR0.GATE always the same thing as SrcClk.Source, or does it depend on the mode of operation?
There's an NI app note and some discussion forum hits if you search the site for "daqmx terminology."
If the M-series hardware manual says to connect something to the SOURCE input, how do I assign an alternate PFI pin to that SOURCE input in Labview? Does it depend on the counter type, or is it always the same?
Usually, that choice would be available under the DAQmx Channel property node.   There'll be some place to define where the input signal is coming from, generally with "Term" or "Terminal" as part of its name.   Sorry I can't be more specific as I'm not at my LV computer now.
Happy counting!
-Kevin P.

Unable to measure frequency below 20 Hz on a NIDAQ 9178 chassis with NI 9402 even while using a hardware timed delay

Hello,
I am trying to measure frequency using NI 9402 in NI cDAQ9178 chassis. I am setting the clock for my counter channel to be my chassis ai Sample Clock.
I am able to measure frequency above 20 Hz. For frequencies less than 20Hz, I get the following error:
DAQmx Error: Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. Ifyou are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches.Task Name: _unnamedTask<0>
Status Code: -201314
Setting the Rate to 1 also not does resolve the issue.
OTHER DETAILS:
* Running on 64 bit, Win7 platform.
* NIDAQmx Driver Version: 14.5
I had posted regarding this earlier and I was told that this might be because the counter is armed immediately before the first sample is taken. The recommendation was to add a hardware-timed delay using the DAQmxSetStartTrigDelay method to the AI task. I have added this delay but I still receive the same error message. The previous post I had mentioned can be found below:
http://forums.ni.com/t5/Multifunction-DAQ/Cannot-measure-frequency-below-20-Hz-on-a-NIDAQ-9178-chassis/td-p/1537274
I have also attached my current code which has the delay. Is this a bug in the driver? If yes, can we have a CAR# to track this?
Thanks.
Regards,
Varun Hariharan
The MathWorks

Alright so I got everything working correctly in both C and LabVIEW code.
The problems is in fact with the first sample, as John_P1 suggested. You simply need to delay that first sample from being requested. It is simple to do this in software instead of hardware.
If you are using CVI, just add #include <utility.h> to the top of your .c file and then add a delay before your DAQmxErrChk (DAQmxStartTask(AItaskHandle)); line.
Comment out / remove the DAQmxSetStartTrigDelay(AItaskHandle,10); line, as it wasn't doing what we thought it would. (Hardware delay).
I added Delay (.05); to delay long enough for the full period of the input signal at 20 Hz.
Depending on your frequency, this value may need to be adjusted. 100ms wouldn't be a bad idea.
This is expected behavior, and I don't think we need a CAR.
Let me know what you think!
-CB

Retriggerable buffered counting edge task

Dear all,
I have been working on "Retriggerable buffered counting edge task" on a single counter input channel, let me describe what I want to achieve:
Create a CI to count finite rising edges with external sample clock (eg. Dev1/di/SampleClock) at certain sampling rate, and set CI.edge.Term at one PFI which is hardwired to another digital input channel. Furthermore, I'd like to set "retriggerable start trigger" to this CI by another PFI line.
It turns out that I can only set "arm start trigger" on this counter input channel, instead of "start trigger" since the error of 200452: attribute not supported in task context showed up at configuring digital edge start trigger. It seems that I can only set "retriggerable start trigger" on counter output task, and use two counters to achieve above, but I was wondering if there is a way to accomplish by single counter. Any suggestion is highly appreciated.
Solved!
Go to Solution.

Dear John,
I just tried and run into another issue with overflow. The idea is to synchronize this counter with finite DI and to read both buffers out when DI's buffer is filled. Since I am running CI in contineous mode, it seems to be reasonable to run into overflow on buffered CI after a couple of triggers; Error: -200279 when trying to read CI buffer. Is there a way to skip/ignore overflow but still read buffer with size that I specified at attribute of SamplePerChannel? or any better idea of design to achieve what I am trying to do? I was wondering how effective it would be by increasing buffer size to avoid overflow since no known pattern on the trigger signal.
Really appreciate your help. Thank you.

Hardware-timed counting of two TTL sources with a pair of PCI-6014's

First, in a nutshell: I'm trying to count TTL pulses from two photon
detectors with short (.1-1 ms) integration times, for fluorescence
correlation spectroscopy. I have a pair of PCI-6014 DAQs, each with a
BNC breakout box.
First I created a LabView vi in which the counter from Dev1 outputs a
pulsetrain of the appropriate integration time, and then Dev1/CTR0 out
is physically routed to Dev2/PFI0 to time the acquisition of TTL pulses
on Dev2/CTR0. This seemed to work fine. The vi is attached below
(1_counter_works).
Then I added a second counter task, using Dev2/CTR1. Up until now
I've
been using a LabView vi in which I use this same idea, but with a
software-timed loop for integration times of >5ms. Software
timing
is too slow for shorter integration times, which is why I'm trying to
use hardware timing. But when I add the second channel, I
get the error "No DMA channels available", which is reasonable, I
guess, because each pci6014 only has one DMA channel. So then I
tried to measure and queue the data in one loop structure, then pass it
to a second loop structure to analyze and display the output (and
eventually I will also update a large data array). But I still
get the same DMA error. That vi is also attached below
(2_counters_queue_notworking). Perhaps I'm not doing the queueing
correctly. I also tried doing the counter measurement and
queueing sequentially in a flat sequence, but was unsuccessful.
This question seems to have come up several times recently, but not
with the exact hardware I have. I've looked through
this thread,
this one, and this one,
and haven't been able to solve the problem on my own.
Can anyone tell me if this is going to be possible with the hardware I have, and if so, how to go about employing queueing to
Attachments:
1_counter_works.vi ‏96 KB
2_counters_queue_notworking.vi ‏134 KB

Problem solved by adding a DAQmx channel properties step, specifying
the data transfer mechanism as 'Interrupts' instead of 'DMA'.

Buffered Counter Start/Stop

I am currently running an application requiring buffered counting
of high-speed events. I have a PC-6602, and I will be running three
groups of two counters each--one counter will run at 20 MHz for high
resolution timing, and the second counter in each group will count
rollovers of the fast counter to keep real time data. For neatness, I
would like to have three separate gruops of counters, but will they start
at the same time? I need all the counters to start simultaneously, and if
they are in different groups with different task ID's, how can I assure
they will all start at the same time?
Thanks,
Josh

Thanks for the response Filipe, I'll let you know how it goes. I only went into the header file because example code provided by NI ... paste ...
iStatus = GPCTR_Read_Buffer(iDevice, ulGpctrNum, ND_READ_MARK, ulReadOffset, ulNumPtsToRead, ulTimeOut, &ulNumPtsRead, pulReadBuf);
showed use of 8 parameters - in agreement with the header file and in disagreement with the on-line help file function documentation.
Tom

PXIe-4141 hardware timed 4- channel sweep

In the attached example of FET/BJT characterisation using hardware timed two channel sweep, for each gate voltage the drain values are sweeped.
If I understand the trigger settings correctly :-
For each drain value, V is applied and I is measured. So if there are 2 Vg values and 3 Vd values, the PXI fetches 6 Vd & Id and 2 Vg, Ig values.
To put it more bluntly,
seq start
Vg = 3V Ig = .....
seq start
Vd = 0.5,Id = ....(Ig = ?)
Vd = 1,Id = ....(Ig = ?)
Vd = 1.5 Id = ....(Ig = ?)
seq complete
Vg = 4V, Ig = ......
seq start
seq complete
What if we wish to measure Ig for all iterations of Vd as well ? Can guess to configure 'MeasureWhen' trigger of Gate to 'SourceComplete' of Drain. Is that doable/feasible in sequence-source-mode ? Or one should apply each value in single-point-source-mode. Wish to iterate 5 values in each 4 cascaded channels at the end.

Hello,
Last time I asked for your code but I think that you need more information about the hardware configuration for your PXI. That is why I found some material in the help file of the PXIe-4141 which is given below.
I hope this helps!
•Once the sequence runs Sequence Loop Count times, the operation is complete, and NI-DCPower generates the Sequence Engine Done event, as shown in the following figures.
The following figure illustrates a sequence with the niDCPower Measure When property is set to Automatically After Source Complete or the NIDCPOWER_ATTR_MEASURE_WHEN attribute is set to NIDCPOWER_VAL_AUTOMATICALLY_AFTER_SOURCE_COMPLETE.
The figure could you find in the screenshot.　
You can find a screecshot in the attachment.
Regards,
Hossein
Attachments:
Help PXIe-4141.png ‏250 KB

Need urgent help with HSDIO hardware timing

Hi everyone,
I need urgent help regarding HSDIO hardware timing. I've been working in a project which generating serial ramp using HSDIO pxie device.
I'm using clock rate 40MHz and generating 14 bit of boolean for each step of ramp. And I have to generate simply 256 steps ramp.
Which means, 256 (steps) x 14 (boolean array) x 25 ns (period of 1 boolean value) = 89,6 ns.
What I'm doing right now is with using index of FOR loop as my input data (converting the index into 14bit boolean), then write into pxie device in every iteration,
which means, my data is getting into output in every 1ms time, right? (I'm using windows)
And I want to be able to generate faster than that.
How can I prewrite my 256 steps ramp, then write them all at once into pxie device. I'm really stuck here.
In the picture can you see how I do the write into device in every iteration of FOR Loop.
Regards,
Yan.

hi, thanks for responding.
with using example of dynamic generation with script, I can manage to generate the ramp with controllable delay (generate the whole waveform, including delay with script command, then write to the card).
But I still have 1 question, I can test the output of the generation using oscilloscope and cant see the start delay (I'm writing delay at the start, before generating the ramp). My signal generated at 0 sec.
How can I check this start delay? is there any good example delivered with Labview to check this generation? Somehow I cant use the "dynamic generation and acquisition" example to see my generation (cant figure out how to capture the generated signal).
regards,
Yan.

Using cDAQ timers to repeat a hardware-timed finite-sample pulse train clock

Hi all,
As part of a complex project, I must implement an acquisition hardware interface for a linear motion sensor using the Synchronous Serial Interface (SSI) output common in industrial motion control. (I have a fair bit of experience in digital electronics, but I'm new to hardware timer-synchronized digital I/O in LabVIEW.)
To do this, I need to create a hardware-timed bursted pulse train TTL clock signal. Each burst consists of 25 high-low transitions with a full-cycle period of 2.67 microseconds (375kHz). The output must then be held high until the next burst, which occur at 1ms intervals.
Using cDAQ timers and a NI 9401 (based on the example at http://www.ni.com/example/30256/en/), I've been able to create the pulse train burst as described (see attached VI image). Next I need to configure another timer to trigger this burst to repeat at 1ms intervals.
Does anyone have any pointers about the best way to accomplish the hardware timing for repetition of the pulse train?
Any suggestions of alternative strategies or observations as to the ways my noobish code is stupid or inefficient are welcome as well!
Thanks!
Solved!
Go to Solution.
Attachments:
Hardware Timed Pulse Train Clock.jpg ‏102 KB

Hey Ryan,
A picture of the behavior you are seeing would be helpful. The NI 9411 should only be reading 50 bits every 1 ms.
It may not be possible to read 25 bits (do you mean 50 bits? 25 high 25 low) and push it to a queue without encountering an overflow error. If you take a look at the above code the digital input will receive 50 sample clocks every 1 ms. This is equivalent to acquiring 50 points every 1 ms which is an acquisition speed of 50 samples/1 ms=50 kHz. The read loop must keep up with the 50 kHz rate otherwise the buffer will overflow. In the above example I’ve set the read to pull 5000 samples (x) with the assumption that the loop will take less than or equal to .1 seconds (y). This yields a software acquisition speed of 50 kHz (5000 samples/100 ms). If the loop speed is faster than 100ms then the 10 seconds timeout on the DAQmx read will allow for the read to block so the FIFO may be filled.
The options available for question 2 are below. They may be used separately or in conjunction.
Move the DAQmx Read for the NI 9411 to its own independent while loop, set the DAQmx Read to acquire 50 samples, do not graph the data, and pass the data to a Queue for processing in a consumer loop. This will increase the loop speed which may allow you to keep up with the 50 kHz acquisition speed. This may not work because the loop speed will need to be 1 ms or less.
Increase the value of the Samples per Channel control that goes into the DAQmx Timing VI. This will increase the DAQmx Software Buffer size. This buys time until you receive an overflow error because the DAQmx Software Buffer is being filled faster than samples are removed.
Read in 5000 sample chunks (producer loop), push this to the queue, and perform the analysis in 50 bit chunks (consumer loop). The additional queue created should allow for the acquisition loop to keep up.
Regards,
Izzy O.
Product Support Engineer
ni.com/support

Synchroniz​e hardware timed buffered counter acquisitio​n with buffered analog input acquisitio​n

Similar Messages

Maybe you are looking for

Synchronize hardware timed buffered counter acquisition with buffered analog input acquisition