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

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

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(sourceSelect); // (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_Command::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::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(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_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_Synchronization(0);
   tio->G1_Counting_Mode.flush();
   //MSeries.CTR.EnableOutput
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Enable(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_EnableOutput);
   //board->Analog_Trigger_Etc.setGPFO_1_Output_Select(tMSeries::tAnalog_Trigger_Etc::kGPFO_1_Output_SelectG_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_Arm_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(sourceSelect); // (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_Command::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::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(tTIO::tG1_Mode::kG1_Trigger_Mode_For_Edge_GateGate_Does_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();
// 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_Synchronization(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.

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.

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

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.

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.

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

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

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.

DAQmx non-cumulative buffered edge counting (like the PMT TTL problem) with PCI6221 in C program environment

I have a PCI-6221. I am programming in C/C++ and DAQmx. My application is much like the previous thread counting the number of asynchronous TTL pulses from a PMT in some user specified time interval. The time interval is typically around 1 msec and the signal rates are around 1-10 kHz. So I expect to count 0 to 10 pulses per timebin. In traditional DAQ this was called Non-cumulative buffered edge counting.
To get a clock at about 1kHz, I first create an "analogue in" task that samples at 1kHz. The only thing I use this task for is to route its sample clock to the gate of the counter. This defines my time interval as 1 msec.
I then create the counter task. I am using count edges. So I think counter0 gate = PFI9 and source = PFI8.
DAQmxCreateCICountEdgesChan(*taskHandle,chan,"",edge,initialCount,countDirection);
DAQmxCfgSampClkTiming(*taskHandle,clockSource,rate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,samplesPerChan);
where clockSource="/Dev1/ai/SampleClock"
I apply my signal to PFI8.
After starting the task, I read an array of values with
DAQmxReadCounterU32(taskHandle,samplesToRead,10.0,data,samplesToRead,read,NULL);
I expect the array data to have values ranging from 0-10 for PMT input with an average rate of about 10 kHz. The trouble is that the array data does not seem to make sense. I get constantly increasing values. For very low input frequency, it just increments by one per array member.
More troublesome, when I hold PFI8 at ground, so that I expect zero pulses to be counted at the source for each edge at the gate that occur 1 per msec, I get a timeout error. I really must be able to count zero events per bin.
Am I doing something obviously wrong?

Hello,
The behavior of non-cumulative event counting is equivalent to period measurement. Additionally, the timeouts when no edges occur on your event counting terminal are the result of duplicate count prevention. In DAQ 7.4, the default behavior of duplicate count behavior should take care of this for you, but if you cannot upgrade to DAQ 7.4, I'd do a search of the discussion forums for "duplicate count prevention". There are a number of previous posts about this attribute, including this one.
If you aren't using the second counter on your device, you should be able to use the Period Measurement 2 Counter High Frequency measurement method to get your desired values. The "Measurement Time" attribute in this case would be the "sample clock" (1 kHz in your example). Then just raed the data raw to get counts rather than scaled.
If you'd like to do it using the AI timing engine. Configure a 1 counter period measurement task, use "clockSource" as your input terminal and use your PMT TTL pulses as the "Counter Timebase Source". Then read the data raw, since the scaling will not be appropriate for your needs.
I hope this helps!
gus....

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

Error -200141 when doing buffered events with DAQmx and PCI-6602

When doing buffered events with DAQmx and PCI-6602 I get error 200141 - Data was overwritten before it could be read by the system.
This error is generated ONLY with random inputs >200/sec.
My setup is :
DAQmxCreateCIVCountEdges(taskhandle,"Dev1/ctr3"....
DAQmxCG+FGSampClkTiming(taskhandle,"/Dev1/FPI35",...
DAQmxSetCICountEgdesChan(taskhandlem,"", "/Dev1/80MHZTimeBase")
DAQmxSetChanAttribute(taskhandlw,",",DAQmx_CI_DataXferMech,DAQmx_Val_DMA,0);
Can somebody help ?

i'm getting the same Error-200141, while reading semiperiods. (Meas_Buffered semiperiod continous)
while loop ex.rate seems to be pulsewidth*no.Samples to read. in my case PW=60ms
Input buffer size measured with Property node= 10000
why this error happens?? i cant use any mode other than implicit timing for semi-period measurement right??
more info: all the ai channels are used ~ 16 differencial.
i found one solution which is _ reinitializing the whole task if an error occur. is this the right way??
Kudos always welcome for helpful posts
Attachments:
Counter_1_Meas Buffered Semi-Period-Continuous_main_lv09.vi ‏34 KB
SemiPeriod_Reconnect Counter on Error.vi ‏35 KB

Gated event counting for a finite time

I am using a PCI 6110 card for gated photon counting. The digital signal is coming from a single photon counting module, which generates a single TTL pulse upon receiving a photon. It also generates ~100 dark count /sec. To get rid of the dark counts, I use gate pulses with very small duty cycle. In this way, the dark counts are suppressed. I want to operate for a fixed time interal with a resolution of ~1ms. My gate pulses are at 800kHz. Their duration is on the order of 10ns. Is there a way that I can perform gated counting for only 10000 gate pulses? Thanks.

Hi UMeng,
Your question stirred up an interesting discussion at the office. You can't do gated, buffered counting as the gate input is used to trigger the latch to the buffer. We came up with a couple of ideas here, but neither are perfect. It is important to also consider that you are running right at the specifed minimum pulse durations for the gate and source pulse durations for the 6110, which is 10 ns.
NI PCI-6110/6111 Specifications
http://digital.ni.com/manuals.nsf/websearch/A9694D34EF10469386256E3000539747
With that in mind, you could use an external high speed AND gate to generate a signal for a simple event counter to read using the laser gate and the photon detector output as input to the AND gate.
Otherwise, you could try doing gated event counting on the signal and simple event counting on the gate as long as the gate frequency is consistent. Then you could use the frequency of the gate and number of counts of the gate to get the total acquisition time. This will require that you start and stop both counter tasks at as close to the same time as possible. The start could be triggered with an Arm Trigger. Getting the values from the counters would always require 2 software calls, but the longer the acquisition, the less important this error would become.
Let me know if either of these sound appealing.
Regards,
John Bongaarts
AE Specialist - Test Products

Why is buffered event counting cumulative

Similar Messages

Maybe you are looking for