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.

Similar Messages

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

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

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

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.

M-series counter interrupts/dma

I'm trying to get the counters on an m-series board (6281) to generate interrupts, so I can do buffered event counting. As a test, when I turn on terminal count interrupts, then make the counter count down to zero, no interrupt is generated. It is disarming when it hits the TC (I have it configured to stop counting and disarm on TC) but no interrupt. I have the TC interrupt enabled in the interrupt A enable register (i'm using counter 0), and I am able to generate TC interrupts using an e-series board. I've noticed the m-series has some additional bits in the Gi_DMA_Config register and I've played with them but to no effect.
Is there any extra magic to make counter interrupts work on m-series boards? Is there any example code of buffered counting using m-series boards (there's none in the m-series ddk, although there is for the 660x boards in the 660x ddk)? Ultimately, I'd like to get buffered counting working with DMA, but for now I'd just like to get it to generate an interrupt.

Hi fmhess-
I created an example recently for DMA-based buffered period measurement. It's attached as gpctex6.cpp and should be a good starting point (along with gpctex1.cpp from the M Series MHDDK) to get buffered edge counting with DMA working. This should give considerably better performance than interrupt-based transfers; will DMA-based transfers (using the MHDDK's DMA library) work for your app?
Thanks-
Tom W
National Instruments
Attachments:
gpctex6.cpp ‏12 KB

NI 6602 buffered pulse width and buffered period measurement with 2 counters synchronized

I modify the example buffered event counting with 8 counters for use with 2.I obtain error 10600 or 10455 and never the waited values.Can you give me a VI example . Thank you for your help

What changes did you make to the VI? If you attached the altered example I could take a look at it. The example program for using 8 counters performs some configuration that you won't need for just two counters. For instance, if you just want to use counters 0 and 1, you won't need to perform pad synchronization.
I've altered the program to use with two counters and attached it to this response. Hopefully this will work for you.
Regards,
Todd D.
NI Applications Engineer
Attachments:
Buffered_Event_Counting_(2).vi ‏126 KB

Gated-event counting using analog triggers?

I'd like to software trigger gated-event counting with analog signals. eg. Use a comparison to check analog input levels to a 6024E card, once a trigger level is reached send a digital out from the 6024E to a 6601 gate to commence and terminate a counter of the 6601 card.
I have found that the counter on the 6024E card is not stable enough for this application, but the NI-TIO cards work reliably.
Any tips greatly appreciated,
Alan

Alan;
In case you want to trigger a finite pulse train generation of an analog hardware trigger, you can still accomplish that with an e-series board only.
You will need to use both general purpose counters available on the DAQ device though. The first counter needs to be configured as retriggerable pulse generation, having its gate being routed to the AI Start Trigger pulse of the Analog Input task. With that done, the counter will generate a pulse at its output at every time the Analog Trigger level is met. You, then, configure the second counter to execute a continuous pulse train and route the first counter output to the second counter gate input. That will make the second counter to generate a pulse train that will be "enabled" by the first counter. The p
ulse train will be generated while the output of the first counter is on its high state level.
Knowing that, you can configure the pulse width of the first counter to be as wide as you need the second counter to generate the pulse train.
Hope this helps.
Filipe A.
Applications Engineer
National Instruments

Buffered Edge Counting 20 MHz with duplicate count prevention

Dear all,
I went through the specs of several boards (M- series, S- and E- series, 6602 etc...). It seems that these boards can count edges with duplicate count prevention on at a maximum rate <= 20 MHz (i.e., 1/4 of 80 MHz) - but maybe I have misunderstood the docs.
Is there a NI board capable of buffered edge counting with a general purpose counter for random events going at rates from 0 Hz to > 20 MHz? Do I need to look for a reconfigurable board?
Thanks in advance.

Dear Elizabeth,
Thanks for the answer.
In my application, events arrive asynchronously (actually, randomly). During the duration of a gate (namely, 1 microsecond), one expects anything from 0 to many (i.e., possibly more than 20, up to 80) events. This requires duplicate count prevention.
I may have misunderstood the specs for M series boards, but the document:
Using Duplicate Count Prevention for Counter Tasks in NI-DAQmx
from the NI web site, for instance, states that:
"All the other timebase edges that occur while the external source input is high are ignored. If no source edges are detected between two gate edges, as shown in Figure 3, duplicate count prevention ensures that pulse measurements return zero because the external source must be logic high to allow the internal timebase to increment the count register. This reduces your maximum source frequency to quarter of the original maximum (80MHz) timebase for NI-STC II and NI-TIO boards. Therefore duplicate count prevention should only be used if the frequency of the Source signal is 20 MHz or less.
Duplicate count prevention should only be use in the following situations:
Counter measurements
The counter Source is using an external signal (such as PFI x)
The frequency of the external source is 20 MHz or less
What's your take on that?
Thanks for your time.

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

Similar Messages

Maybe you are looking for