I want to read 0 count in buffered event counting mode

Hi, I am using the NI6602 board with DAQmx ANSI C. My aplication uses six counters in buffered event counting mode, 0 events is a valid value for me, but when the gate signal arrives the 0 value isn't written to the buffer. Instead the function DAQmxCreateLinScale() returns a timeout error. How can I solve it?
Thanks.

alegrecd,
I'm afraid I don't know the syntax for doing this from C with explicit DAQmx calls. But I think you need to look into turning ON the property called "duplicate count prevention." The name isn't the most descriptive of the actual behavior.
Normally the property is OFF. In such case, the counter expects the Source signal (which increments the internal count register) to be faster than the Gate (or "sampling clock") signal. If no Source edges are seen between successive Gate edges, the count value is NOT put into the data acq buffer.
If you turn the property ON, then the count values WILL be written to the buffer, even if no source edges have occurred between successive Gate edges.
-Kevin P.

Similar Messages

  • Buffered event counting. Why can't I explicitly sequence generating the Sample Clock Pulse and reading the counters?

    At irregular occasions I need to grab counts from several counters, and buffering the counts must be done simultaneously for all counters. I'm modeling my approach after zone.ni.com/devzone/cda/tut/p/id/5404 which someone kindly pointed out in an earlier thread. However, that example only uses one counter, and you can't test the synchronization with only one counter, so I am using two counters configured the same way, and they're wired to a single benchtop signal generator (for example at 300 kHz).
    What I want to do, I can test in a loop with a somewhat random wait in it. I want to drive a hardware digital output line high for a few ms and then low again. The hardware line is physically connected to terminals for my timing vi's Sample Clock Source and so will cause them to buffer their counts for later reading. After I pulse this line, when I know new good buffered counts await me, I want to read both my counters. If their bufferings are simultaneous, then each counter will have counted the same number of additional counts since the last loop iteration, which I can check by subtracting the last value sitting in a shift register and then subtracting the two "additional counts" values and displaying this difference as "Diff". It should always be 0, or occasionally +1 followed immediately by -1, or else the reverse, because buffering and a count could happen practically at the same moment.
    When I do this using a flat sequence to control the relative timing of these steps, so the read happens after the pulse, the counters often time out and everything dies. The lengths of time before, during, and after the pulse, and the timeout value for the read vi, and the size of the buffer and various other things, don't seem to change this, even if I make things so long I could do the counting myself holding a clipboard as my buffer. I've attached AfterPulse.vi to illustrate this. If I get 3 or 10 or so iterations before it dies, I observe Diff = 0; at least that much is good.
    When I use two flat sequences running in parallel inside my test loop, one to control the pulse timing, and the other to read the counters and do things with their results, it seems to work. In fact, Diff is always 0 or very occasionally the +/- 1 sequence. But in this case there is nothing controlling the relative timing such that the counters only get read after the pulse fires, though the results seem to show that this is true. I think the reads should be indeterminate with respect to the pulses, which would be unreliable. I don't know why it's working and can't expect it to work in other environments, can I? Moreover, if I set some of the pulse timing numbers to 1 or 2 or 5 ms, timeouts start happening again, too. So I think I have a workaround that I don't understand, shouldn't work, and shouldn't be trusted. See SeparateSequence.vi for this one.
    I also tried other versions of the well-defined, single sequence vi, moving the counter reads to different sequence frames so that they occur with the Sample Clock Source's rising edge, or while it is high, or with the falling edge, and they also often time out. I'll post these if anyone likes but can't post now due to the attachment limit.
    Here's an odd, unexpected observation: I have to sequence the reads of the counters to occur before I use the results I read, or else many of the cycles of this combine a new count from one counter with the one-back count from the other counter, and Diff takes on values like the number of counts in a loop. I though the dataflow principle would dictate that current values would get used, but apparently not so. Sequencing the calculations to happen after the reads fixes this. Any idea why?
    So, why am I not succeeding in taking proper control of the sequence of these events?
    Thanks!!!
    Attachments:
    AfterPulse.vi ‏51 KB
    InSeparateSequence.vi ‏49 KB

    Kevin, thanks for all the work.
    >Have you run with the little execution highlighting lightbulb on? -Yes. In versions of this where there is no enforced timing between the counter and the digital line, and there's a delay inserted before the digital line, it works. There are nearly simultaneous starts on two tracks. Execution proceeds directly along the task wire to the counter. Meanwhile, the execution along the task wire to the digital high gets delayed. Then, when the digital high fires, the counter completes its task, and execution proceeds downstream from the counter. Note, I do have to set the timeout on the counter longer, because the vi runs so slowly when it's painting its progress along the wires. If there is any timing relationship enforced between the counter and the digital transition, it doesn't work. It appears to me that to read a counter, you have to ask it for a result, then drive the line high, and then receive the result, and execution inside the counter has to be ongoing during the rising line edge.
    >from what I remember, there isn't much to it.  There really aren't many candidate places for trouble.  A pulse is generated with DIO, then a single sample is read from each counter.  -Yup, you got it. This should be trivial.
    >A timeout means either that the pulse isn't generated or that the counter tasks don't receive it. - Or it could mean that the counter task must be in the middle of executing when the rising edge of the pulse arrives. Certainly the highlighted execution indicates that. Making a broken vi run by cutting the error wires that sequence the counter read relative to the pulse also seems to support that.
    >Have you verified that the digital pulse happens using a scope? -Verified in some versions by running another loop watching a digital input, and lighting an indicator, or recording how many times the line goes high, etc. Also, in your vi, with highlighting, if I delete the error wire from the last digital output to the first counter to allow parallel execution, I see the counter execution start before the rising edge, and complete when the line high vi executes. Also, if I use separate loops to drive the line high and to read the counter, it works (see TwoLoops.vi or see the screenshot of the block diagram attached below so you don't need a LV box). I could go sign out a scope, but think it's obvious the line is pulsing given that all these things work.
    >Wait!  I think that's it!  If I recall correctly, you're generating the digital pulse on port0/line0...  On a 6259, the lines of port 0 are only for correlated DIO and do not map to PFI. -But I'm not using internal connections, I actually physically wired P0L1 (pin 66) to PFI0 (pin 73). It was port0/line1, by the way. And when running some of these vi's, I also physically jumper this connection to port0/line2 as an analog input to watch it. And, again, the pulse does cause the counter to operate, so it clearly connects - it just doesn't operate the way I think it is described operating.
    For what it's worth, there's another mystery. Some of the docs seem to say that the pulse has to be applied to the counter gate terminal, rather than to the line associated with the sample clock source on the timing vi. I have tried combinations of counter gate and or sample clock source and concluded it seems like the sample clock source is the terminal that matters, and it's what I'm using lately, but for example the document I cited, "Buffered Event Counting", from last September, says "It uses both the source and gate of a counter for its operation. The active edges on the gate of a counter is used to latch the current count register value in a hardware register which is then transferred via Direct Memory Access...". I may go a round of trying those combinations with the latest vi's we've discussed.
    Attachments:
    NestedSequences.png ‏26 KB

  • Doing Buffered Event count by using Count Buffered Edges.vi, what is the max buffer size allowed?

    I'm currently using Count Buffered Edges.vi to do Buffered Event count with the following settings,
    Source : Internal timebase, 100Khz, 10usec for each count
    gate : use the function generator to send in a 50Hz signal(for testing purpose only). Period of 0.02sec
    the max internal buffer size that i can allocate is only about 100~300. Whenever i change both the internal buffer size and counts to read to a higher value, this vi don't seem to function well. I need to have a buffer size of at least 2000.
    1. is it possible to have a buffer size of 2000? what is the problem causing the wrong counter value?
    2. also note that the size of max internal buffer varies w
    ith the frequency of signal sent to the gate, why is this so? eg: buffer size get smaller as frequency decrease.
    3. i'll get funny response and counter value when both the internal buffer size and counts to read are not set to the same. Why is this so? is it a must to set both value the same?
    thks and best regards
    lyn

    Hi,
    I have tried the same example, and used a 100Hz signal on the gate. I increased the buffer size to 2000 and I did not get any errors. The buffer size does not get smaller when increasing the frequency of the gate signal; simply, the number of counts gets smaller when the gate frequency becomes larger. The buffer size must be able to contain the number of counts you want to read, otherwise, the VI might not function correctly.
    Regards,
    RamziH.

  • Retriggerable buffered event counting

    I have been programming with Labview for the last 3 years, but know i have a problem:
    Anybody know if is possible to do a retriggerable buffered event counting?
    Thanks for your time.

    Jofre,
    Mark's suggestion is definitely a simpler and cleaner solution. I've done a pretty similar thing in the past with a 6602 and traditional NI-DAQ. I'd just add two more thoughts to go with his method:
    1. You'll want to configure both the counters to be started by the same digital trigger signal so that their time information is synchronized, i.e., they both have the same "0" time.
    2. You may need to watch for counter rollover, which occurs in less than a minute at 80 MHz. Not a real big deal, just a little thing to watch for when processing the data.
    It could get a little trickier if your trigger signal is relatively rare (once or twice a minute or less). In such cases, you stand the risk of not knowing whether the counter rolled over between triggers or how many times. To help this problem, you could use a slower timebase (probably the 100 kHz) as a source for timestamping the triggers. There are other possibilties requiring the use of additional counters.
    Other comments:
    - Heed Mark's tip about group # if using Counter Config under traditional NI-DAQ.
    - If you aren't heavily committed to traditional NI-DAQ, I'd suggest doing this with DAQmx. I admit that I struggled a while when making the switch but half of the effort was unlearning old ways. I've been using only DAQmx for all new development and I'd venture that for about 80-90% of the functions and features, I prefer it.
    - (for academic interest only). It actually *is* possible to use the Z-index reload feature when configuring a counter for position/encoder measurement with a "two-pulse" encoder. You would simply hardwire one of the two inputs to digital ground, and configure the Z-index reload phase to "A LOW B LOW." There would still be two problems for the app in question here.
    1. In encoder mode, the up pulse and down pulse must be signals wired to the counter's default SOURCE and AUX/UPDN pins respectively. You would need to somehow bring the internal 80 MHz timebase clock out to your terminal block pins. (I *think* but am not 100% sure that this can be done, but possibly only with DAQmx). Also, the reset signal must likewise be hardwired to the counter's default GATE pin.
    2. The Z-index reload pulse seems to operate in a level-sensitive mode rather than edge-sensitive. As I recall from testing, if the trigger pulse remains in a HIGH state during several encoder pulses, the count keeps resetting after each one. One the other hand if it pulses briefly within the time that the A input is HIGH, no reset will occur. (Many industrial measurement encoders are designed to meet these Z-index requirements right out of the box.)
    The more I think about it, the more I REALLY REALLY think there should be a setting that lets you reset a counter to a specific reload value on an EDGE of a software-defined GATE/TRIGGER signal.
    Anyway, good luck with things.
    -Kevin P.

  • M-Series Buffered Event Counting with DMA -- gating problem

    Hi --
    I am implementing DMA-based buffered event counting on a PCIe-6259 board.  I use G0_Out as the gate for G1, which counts events on a PFI pin.   So by setting the speed of G0, I get an event count (either cumulative or non-cumulative) on a periodic basis, which is directly DMA'd to my buffer, and synchronized with other i/o operations.
    This is working well right now, except for one problem, which is that the I only get data if there is at least one  source edge between gates.  i.e. if there are no edges, nothing gets pumped to the dma buffer.
    I am guessing that a stale data error is somehow choking off the DMA transfer from the counter.   Is that possible?
    Is there some magic that I need to do to avoid this, because for this application, especially if I am counting cumulatively, I don't care about a missing edge, but I do care if the dma transfers get out of phase with the rest of my timing.
    Thanks in advance for any help!
    --spg
    Here is a snippet of the code that sets up the event counting on G1, partly based on gpctex6.cpp:
    const int sDMASelect[] = {1,2,4,8,3,5};
    // source:  pfi, or -1 for 20Khz clock
    void eventTimerSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source)
        int sourceSelect = (source==-1) ? 0 : (source+1);
        //MSeries.CTR.Source
        tio->G1_Input_Select.setG1_Source_Select(sourceSe​lect); // (pfi+1) or 20Khz=0
        tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
        tio->G1_Input_Select.setG1_OR_Gate(0);
        tio->G1_Input_Select.flush();
        //MSeries.CTR.Gate
        tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
        tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
        tio->G1_Input_Select.flush();
        //MSeries.CTR.IncrementRegisters
        tio->G1_AutoIncrement.writeRegister(0);
        //MSeries.CTR.InitialCountRegisters
        tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1​_Mode::kG1_Load_Source_SelectLoad_A);
        tio->G1_Load_A.writeRegister(0);
        tio->G1_Command.writeG1_Load(1);
        tio->G1_Load_B.writeRegister(0);
        tio->G1_Load_A.writeRegister(0);
        tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG​1_Command::kG1_Bank_Switch_EnableBank_X);
        tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_​Command::kG1_Bank_Switch_ModeGate);
        tio->G1_Command.flush();
        //MSeries.CTR.ApplicationRegisters
        tio->G1_Input_Select.setG1_Gate_Select_Load_Sourc​e(0);
        tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::​tG1_Mode::kG1_Reload_Source_SwitchingAlternate);
        tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_​Gate);
        tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::​kG1_Loading_On_TCRollover_On_TC);
        tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active​_High);
        tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_​Disabled);
        tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTI​O::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Do​es_Not_Stop);
        tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_​Stop_ModeStop_On_Gate);
        tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::​kG1_Counting_OnceNo_HW_Disarm);
        tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode​(0);
        tio->G1_Input_Select.flush();
        tio->G1_Mode.flush();
        tio->G1_Second_Gate.flush();
        //MSeries.CTR.UpDown.Registers
        tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command​::kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
        //MSeries.CTR.OutputRegisters
        tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::​kG1_Output_ModePulse);
        tio->G1_Input_Select.writeG1_Output_Polarity(0);
        //MSeries.CTR.BufferEnable
        board->G1_DMA_Config.writeG1_DMA_Reset(1);
        board->G1_DMA_Config.setG1_DMA_Write(0);  
        board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
        board->G1_DMA_Config.setG1_DMA_Enable(1);   
        board->G1_DMA_Config.flush();
        tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode​(0);
        tio->G1_Counting_Mode.setG1_Alternate_Synchroniza​tion(0);
        tio->G1_Counting_Mode.flush();
        //MSeries.CTR.EnableOutput
        //board->Analog_Trigger_Etc.setGPFO_1_Output_Enab​le(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_E​nableOutput);
        //board->Analog_Trigger_Etc.setGPFO_1_Output_Sele​ct(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_S​electG_OUT);
        //board->Analog_Trigger_Etc.flush();
        //MSeries.CTR.StartTriggerRegisters
        tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_​Arm_Enable(0);    
        board->G0_G1_Select.writeG1_DMA_Select(sDMASelect​[dmaChannel]);   
        tio->G1_Command.writeG1_Arm(1); // arm it
    Scott Gillespie
    http://www.appliedbrain.com
    scott gillespie
    applied brain, inc.
    Solved!
    Go to Solution.

    Okay, I have it working now.  In addition to your suggested changes, I had to remove the following line:
    tio->G1_MSeries_Counting_Mode.writeG1_MSeries_HW_A​rm_Enable(0);    
    It appears that writing something to MSeries_Counting_Mode causes that register to supersede the Counting_Mode register.  Is that right?
    So code that now works for  me is listed below.
    thanks Tom!
    -spg
    void eventCounterSetup(tMSeries *board, tTIO *tio, int dmaChannel, bool cumulative, int source) // pfi, or -1 for 20Khz clock
    int sourceSelect = (source==-1) ? 0 : (source+1);
    //MSeries.CTR.Source
    tio->G1_Input_Select.setG1_Source_Select(sourceSel​ect); // (pfi+1) or 20Khz=0
    tio->G1_Input_Select.setG1_Source_Polarity(0); //rising=0
    tio->G1_Input_Select.setG1_OR_Gate(0);
    tio->G1_Input_Select.flush();
    //MSeries.CTR.Gate
    tio->G1_Input_Select.setG1_Gate_Select(20); //the G_OUT signal from other clock=20
    tio->G1_Input_Select.setG1_Output_Polarity(0); //active high=0
    tio->G1_Input_Select.flush();
    //MSeries.CTR.IncrementRegisters
    tio->G1_AutoIncrement.writeRegister(0);
    //MSeries.CTR.InitialCountRegisters
    tio->G1_Mode.writeG1_Load_Source_Select(tTIO::tG1_​Mode::kG1_Load_Source_SelectLoad_A);
    tio->G1_Load_A.writeRegister(0);
    tio->G1_Command.writeG1_Load(1);
    tio->G1_Load_B.writeRegister(0);
    tio->G1_Load_A.writeRegister(0);
    tio->G1_Command.setG1_Bank_Switch_Enable(tTIO::tG1​_Command::kG1_Bank_Switch_EnableBank_X);
    tio->G1_Command.setG1_Bank_Switch_Mode(tTIO::tG1_C​ommand::kG1_Bank_Switch_ModeGate);
    tio->G1_Command.flush();
    //MSeries.CTR.ApplicationRegisters
    tio->G1_Input_Select.setG1_Gate_Select_Load_Source​(0);
    tio->G1_Mode.setG1_Reload_Source_Switching(tTIO::t​G1_Mode::kG1_Reload_Source_SwitchingAlternate);
    tio->G1_Mode.setG1_Loading_On_Gate(cumulative ? tTIO::tG1_Mode::kG1_Loading_On_GateNo_Reload : tTIO::tG1_Mode::kG1_Loading_On_GateReload_On_Stop_​Gate);
    tio->G1_Mode.setG1_Loading_On_TC(tTIO::tG1_Mode::k​G1_Loading_On_TCRollover_On_TC);
    tio->G1_Mode.setG1_Gating_Mode (tTIO::tG1_Mode::kG1_Gating_ModeEdge_Gating_Active​_High);
    tio->G1_Mode.setG1_Gate_On_Both_Edges (tTIO::tG1_Mode::kG1_Gate_On_Both_EdgesBoth_Edges_​Disabled);
    tio->G1_Mode.setG1_Trigger_Mode_For_Edge_Gate(tTIO​::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Doe​s_Not_Stop);
    tio->G1_Mode.setG1_Stop_Mode(tTIO::tG1_Mode::kG1_S​top_ModeStop_On_Gate);
    tio->G1_Mode.setG1_Counting_Once(tTIO::tG1_Mode::k​G1_Counting_OnceNo_HW_Disarm);
    tio->G1_Second_Gate.setG1_Second_Gate_Gating_Mode(​0);
    tio->G1_Input_Select.flush();
    tio->G1_Mode.flush();
    tio->G1_Second_Gate.flush();
    //MSeries.CTR.UpDown.Registers
    tio->G1_Command.writeG1_Up_Down(tTIO::tG1_Command:​:kG1_Up_DownSoftware_Up); //kG1_Up_DownSoftware_Down
    //MSeries.CTR.OutputRegisters
    tio->G1_Mode.writeG1_Output_Mode(tTIO::tG1_Mode::k​G1_Output_ModePulse);
    tio->G1_Input_Select.writeG1_Output_Polarity(0);
    //MSeries.CTR.BufferEnable
    board->G1_DMA_Config.writeG1_DMA_Reset(1);
    board->G1_DMA_Config.setG1_DMA_Write(0);  
    board->G1_DMA_Config.setG1_DMA_Int_Enable(0);
    board->G1_DMA_Config.setG1_DMA_Enable(1);   
    board->G1_DMA_Config.flush();
    // from Tom:
    // The "magic" you need is referred to as synchronous counting mode (or Duplicate Count Prevention in NI-DAQmx).  
    // Try setting G1_Encoder_Counting_Mode to 6 (synchronous source mode) and G1_Alternate_Synchronization to 1 (enabled).
    tio->G1_Counting_Mode.setG1_Encoder_Counting_Mode(​6); // 0
    tio->G1_Counting_Mode.setG1_Alternate_Synchronizat​ion(1); // 0
    tio->G1_Counting_Mode.flush();
    board->G0_G1_Select.writeG1_DMA_Select(sDMASelect[​dmaChannel]);   
    tio->G1_Command.writeG1_Arm(1); // arm it
    scott gillespie
    applied brain, inc.

  • Buffered event counting: migration from E/M series to NI-USB 6210

    Hello,
    I create a project developed in LabWindows CVI that does buffered event counting.
    The project ran on E/M series for a year. Now I have to migrate to NIDAQ-USB and precisely NI-USB-6210 (that is a M-series). The problem concerns reading acquired samples. The buffered event counting that I need is performed in this way:
    1) Start a buffered event counting task
    2) After n seconds, read the number of samples and read the samples
    3) Stop the task
    This procedure works fine on E/M series on PCI bus, but it does not work with NI-USB. With NI-USB, the number of samples is always 0. I link a project that demonstrates that (the "after n seconds" clause is simulated by pressing "stop" key).
    After many tries, I saw that the problem is in reading number of samples and so I modified the sequence of operation in this way:
    1) Start a buffered event counting task
    2) After n seconds, try many times to read the number of samples
    3) Read the samples
    4) Stop the task
    After some houndreds of attempts, the number of samples moves from 0 to the correct number of samples...It seems a bad working....And I don't know after how many attempts I can surely assert that no samples effectively "crossed" card input....
    Is there an error in my procedure? Have I made some incorrect operations? Or maybe is there a inconsistency in NIDAQmx driver?
    Attachments:
    Provausb.zip ‏463 KB

    Hello Luca,
    I changed the code a bit and I found something interesting about your situation; in the attached VI there is your CVI project modified as follows:
    After the Stop button hes been pressed, and the corresponding callback function is called, we read the acquired samples two times: the first one we ask for 1 sample only. This allows to avoid the USB transfer mechanism issue and then, with the second read function it is possible to get all the remaining samples acquired (selecting -1 as "number of samples to read");
    Hope this helps you,
    Best regards
    Fabio Mussi
    P.S. A SR request about this problem has been opened too. If you need more information, call me at 02-41309217;  
    Fabio M.
    National Instruments
    Embedded & OEM Systems Engineer
    Attachments:
    Provausb_modified_2.zip ‏471 KB

  • Why is buffered event counting cumulative

    I'm trying to do buffered event counting using general purpose counters on an e-series board. It doesn't work quite as advertised. Each point in the buffer is supposed to contain the count of source events that occurred between successive pulses of the gate, according to the Nidaq function reference manual. I find, however, that every point contains the cumulative number of events, so the data are monotonically increasing. Is there a setting somewhere to change this behavior, or is there an error somewhere - either in the documentation, or in the code?
    This was with NI boards 6711 and a 6035 in a G4 running OS 9.

    Gus said:
    "Where in the documentation does it suggest that buffered event counting is not cumulative?"
    page 8-51, NI-DAQ software reference for Macintosh. The example shows the buffer containing values of 4, 2, and 5, corresponding to the number of events between consecutive transitions of the gate, not the cumulative total of events since counting started.
    I have just checked to ensure that buffered period measurement is not cumulative, and it is not (which is good).
    Thanks for the tip.
    jamie

  • Soucis d'utilisation des compteurs avec buffer - Count Single Buffered Events

    Bonjour,
    Voici mon soucis
    Lorsque je scrute le conteur de ma carte ( 6033E ) j'arrive à lire les valeurs sans soucis
    Par contre dès que j'utilise le buffer  ( l'exemple Count Single Buffered Events-Adv (DAQ-STC) dans les exemples )
    pas moyen d'afficher un comptage.
    Avez vous une idée d'ou cela pourait provenir ?
    Merci
    Attachments:
    Count Single Buffered Events-Adv (DAQ-STC).vi ‏193 KB

    ok j'ai trouvé la solution,
    pas facile quand on débute

  • What DAQ products support buffered event counting

    I need to accurately time a series of count events.Buffered event counting sounds like it would work but not sure if it is hardware dependent.

    Hello;
    All boards that have either the STC or TIO counter chips support that operation.
    You can look into all E-series and 660x counter devices.
    Regards
    Filipe A.
    Applications Engineer
    National Instruments

  • Getting 2nd TIO of the PCI6602 to perform buffered event counting via register-level programming

    I got the first PCI6602 TIO to perform buffer event counting using interrupt. However, I could not get the second TIO working. I think I have initialized the proper registers in order to work with the second TIO, i.e.
    1. Addressing all registers of the second TIO at 0x800 offset.
    2. Binding the clock to counter 4-7 (set 0x00200000 to the Clock Configuration register). I am using the internal Timebase_3 clock which is 80MHz.
    3. Tried setting 0x8000 to the Global Interrupt Control register at both its offset location (with 0 offset) and with 0x800 offset (2nd TIO offset location).
    Am I missing something here? I got no interrupts from the PCI bus and I got 0xff
    ff when I tried to read the Status register.

    Al,
    I have been experimenting with the 6602, but I have not been able to see any of the interrupts generated by the counters. I have tried both TC mode and an external signal on a single GATE (G0). The Gi_Status_Register indicates that the interrupts are occuring (appropriately for each mode), but I can't see them on the bus (my interrupt handler is never invoked; cat /proc/interrupts shows 0 interrupts).
    Could you pass along any tips on how you did it?
    Thanks!
    -Rob

  • Peut-on faire du Buffered Event Counting sur carte 6601 avec signaux quadrature?

    L'entrée GATE est utilisée pour index/z et le signal de transfert buffer !

    Hello,
    When you perform Buffered Position Measurement, I/O connections are as described below:
    * Connect the encoder A signal to the source pin of the selected counter (SOURCE)
    * Connect the encoder B signal to the aux line pin of the selected counter (UP/DOWN)
    * If you are using Z indexing, then connect the encoder Z signal to the gate pin of the selected counter (GATE)
    * Connect the data latching signal to the selected gate input of the counter (PFI or RTSI)
    There is a difference between the selected gate of the counter and the gate pin of the counter.
    The gate pin is a specific hardwired pin of the counter.
    The selected gate of the counter is selected using Counter Set Attribute.vi.
    You can use the "Measure Buffered Position (NI-TI
    O).vi" in the Example Finder of LabVIEW to perform a test with Z-indexing from a quadrature encoder.
    I hope this will help.
    Regards.
    Matthieu Gourssies
    National Instruments.

  • Buffered event counting, VB6, DAQmx

    I have an encoder that I would like to count the pulses per revolution on.
    I can do this in Traditional DAQ by setting the Counter Source and Gate.  Source being the encoder pulse train, and the Gate being the index on the encoder.
    How would I do this in DAQmx?  Every example I have seen is for event counting, but nothing to actually give you a PPR.
    Source is channel A of encoder.
    Gate is channel Z of encoder.
    Any source code tidbits will be very much appreciated.
    Thanks for your help.

    Big Guy,
    In DAQmx, the source and gate pins of each counter have default values.  You can find which pins you need to use by opening up Measurement & Automation Explorer (MAX) and then navigating to Devices and Interfaces>>NI-DAQmx Devices>>(Your Device) and then right-clicking and choosing Device Pinouts.  Unless there is an absolute need to use another pin, I'd recommend using the default pins shown below.
    Which DAQ card are you using?
    Default NI-DAQmx Counter Terminals
    Counter/Timer Signal
    Default Pin Number
    Signal Name
    CTR 0 SRC
    37
    PFI 8
    CTR 0 GATE
    3
    PFI 9
    CTR 0 AUX
    45
    PFI 10
    CTR 0 OUT
    2
    PFI 12
    CTR 0 A
    37
    PFI 8
    CTR 0 Z
    3
    PFI 9
    CTR 0 B
    45
    PFI 10
    CTR 1 SRC
    42
    PFI 3
    CTR 1 GATE
    41
    PFI 4
    CTR 1 AUX
    46
    PFI 11
    CTR 1 OUT
    40
    PFI 13
    CTR 1 A
    42
    PFI 3
    CTR 1 Z
    41
    PFI 4
    CTR 1 B
    46
    PFI 11
    Josh W.
    Certified TestStand Architect
    Formerly blue

  • Counting (interneal timebase)events with only one counter

    Hello,
    i am using a PXI-6115 card. This card is external clocked with 8 MHz. But I want to measure only about every second. So I divided the external clock with the internal counter 0. This works fine.
    Now my problem. Now I want to know the external clock rate. Is it possible to build a pulse period measurement with only one counter??
    I thinking of counting internal timebase- pulses with counter 1 and to start and stop the counter 1 by the output of counter 0.
    Is this possible and how??
    Thanks for help, Ruediger

    Yes, there's a way to measure pulse periods with a single counter. The trick is to perform a buffered period measurement and sum the periods. The size of the buffer will determine the quantization/roundoff error.
    The source of this error is that you have no control over the initial phase relationship of your external clock and your internal timebase. There's a nominal ratio between the two frequencies, and you'd start by expecting ratio * (buffer size) total cycles counted.
    However, your actual count must be an integer, so you'll get either the next-highest or next-lowest integer, but you can't predict or control which one.
    Example: If you collect 1 period at 8 MHz using the internal 20 MHz timebase, you'll capture either 2 or 3 e
    dges from your timebase, implying a measured frequency of either 10 MHz or 6.6667 MHz.
    If you collect 1001 periods, you'll capture a total of 2502 or 2503 timebase edges, implying a measured frequency of either 8.0016 MHz or 7.9984 MHz.
    Notes:
    1. In many cases, you can set up for buffered event counting, using the internal 20 MHz clock as a source and your external 8 MHz as a gate.
    The advantage is that the buffered values already represent cumulative time so you don't need to sum them.
    A disadvantage would be that the internal 24-bit counter value will roll-over in less than 1 second at 20 MHz. I typically capture periods and then sum in software because I can convert to floating point between capture and sum if necessary to produce both high-resolution and long duration measurements.
    2. You should typically ignore the very first value in the buffer and work only with the others. If you want to capture 1001 legitimate periods, size the buffer for at least 1002
    -Kevin P.

  • MIO 6601 Counter, Perform Buffered Read and Simple Read

    I have an application written in C++ where I would like to use the 6601 as the time base for all of the boards, so I would like to be able to query the current value of the counter. I also have a external signal that I want time tagged in the buffer. I have used example programs for the Simple Read and the Buffered read and they both work successfully individually.
    If I try and combine them by setting up the counter with the following statement:
    iStatus = GPCTR_Set_Application(iDevice, ND_COUNTER_3, ND_BUFFERED_EVENT_CNT);
    and try to read the current value of the counter with:
    iStatus = GPCTR_Watch (iDevice, ND_COUNTER_3, ND_COUNT, puiCurrentTime);
    I always return a 0 for puiCurrentTime.
    Can
    I do both with a single counter? If not can I synchronize two counters one setup for the buffered read the other for the simple read.
    Thanks

    The second NIDAQ function call (GPCTR_Watch) will not work with Buffered Acquisition, because it is designed for simple read only. That might be the reason why puiCurrentTime always returns a zero.
    Regarding the second issue, you can do both tasks with a single counter, by configuring it as buffered first, and completing the operation, and then configuring it as single, and completing also the operation. Nevertheless, there is no way to configure it as buffered and work with it as single reader, or viceversa. You must use two for performing an operation such as that. Thus, if you want to synchronize both of them, I would suggest you to read the following document which talks about it.
    Well, I hope all of this info is helpful for you.
    Aguila
    Attachments:
    Multicounter_Synchronization_App_Note.doc ‏55 KB

  • Want to trigger event count from both counters (E) to buffer using FOUT (100kHz/16 or slower) as a trigger

    We are using a AT-MIO-16E-1 board. We would like to run an xy raster pattern from the buffer (AO) in order to reduce scan times (256 x 256 pt images). At each AO (voltage) point we would like to read from both onboard counters and store the number of events counted to memory, reading out the buffer say every 256 pts (1 scan line). In order to ensure accurate counting periods the counters need to be triggered to coincide with some "dwell time" at each AO voltage pt. We have thought of using FOUT for the trigger or perhaps out analog out scanning signal but are concerned that the FOUT freq is too high (6250 khz - we would like 100hz-10khz). Any suggestions or e
    xamples would be appreciated.

    Hello;
    The main problem there is going to be the counter triggering. I'm saying that because, there isn't a way for the Analog Input operation to send pulses that will trigger of the timer operation at multiple voltage levels. The only solution for this I can think of is, instead of having an analog voltage level which would indicate the position of xy, if you could have a device which would give a TTL pulse instead when the desired position is reached, then you could use the 6601 to have a triggered operation at the counter. Another constraint for your application right now is the fact that the E-series boards' counters don't have triggering features, only gated features.
    Anyway, you would need to have a TTL pulse either to trigger (in case of the 6601 count
    ers) or to gate (in case of the E-series board), when the desired XY position is reached.
    Meanwhile, you can refer to the Labview examples for Streaming to disk, Analog I/O and counter operations. You can go to Search Examples->I/O Interfaces->Data Acquisition->Data Logger ( for streaming to disk operations); Search Examples->I/O Interfaces->Data Acquisition->Analog Output ( for Analog Output Operations); and Search Examples->I/O Interfaces->Data Acquisition->Counters (for counter operations). Also; I'm including an Application Note which talks about synchronization of multiple DAQ tasks I think will be helpful for you also.
    Regards.
    Filipe
    Attachments:
    Advanced_Sync_Techniques_for_DAQ.pdf ‏189 KB

Maybe you are looking for