Counter complete on PCIe 6321

[zeekial]

I'm trying to send a count complete output pulse to a PFI channel when a counter reaches zero (Ex. Start at count 10 and counter down). The counter appears to be running without error, however the PFI output does not toggle. I know this can be done with an event callback, unfortunately the sotware latencey is insufficient for our application. Any ideas?

DAQmxCreateTask("", &_taskCounter);
DAQmxCreateCICountEdgesChan (_taskCounter, "/Dev1/ctr3","", DAQmx_Val_Rising, 10, DAQmx_Val_CountDown );
DAQmxSetCIFreqTerm(_taskCounter,"","/Dev1/PFI5");
DAQmxExportSignal(_taskCounter,DAQmx_Val_CounterOutputEvent,"/Dev1/PFI15");
DAQmxStartTask(_taskCounter);

[Hey.itsDale]

If I am understanding you correctly, you want to count edges on PFI5 and toggle PFI1?

I would suggest using a Counter Output task with DAQmxCreateCOPulseChanTicks() instead of a counter input task. You can specify the PFI5 as the channel to count edges on using DAQmxCfgSampClkTiming(). Then your output terminal can be PFI1.

[zeekial]

Counter output does not appear to solve the problem.

Below is what I'm looking to achieve. The black line signal will feed into PFI5 and be counted down. When the count reaches the rollover point (zero->int max) I want a pulse generated on another PFI line (ex. PFI 15)  

[zeekial]

Progress. With the modifications below I am now able to output a state change when the count on PFI5 reaches 10. Next I would like to keep the pulse high for specified number of pulses after the initial pulse (Ex. Stay high for 3 pulses after the 10 is reached then go low). My idea is to create a callback that fires when the outputevent occurs and reset the counter with a count of 3 and rearm). Unfortunately when I add the line ( DAQmxRegisterSignalEvent(_taskCounter,DAQmx_Val_CounterOutputEvent,0,CounterOutputCallback,NULL);) to my code below the state change on the output port stops working. Is this expected behavior?

DAQmxCreateTask("", &_taskCounter);
DAQmxCreateCICountEdgesChan (_taskCounter, "/Dev1/ctr3","", DAQmx_Val_Rising, 10, DAQmx_Val_CountDown );
DAQmxSetCICountEdgesTerm(_taskCounter,"/Dev1/ctr3","/Dev1/PFI5");
DAQmxExportSignal(_taskCounter,DAQmx_Val_CounterOutputEvent,"/Dev1/PFI15");

DAQmxSetExportedCtrOutEventOutputBehavior(_taskCounter,DAQmx_Val_Toggle);
DAQmxStartTask(_taskCounter);

[Hey.itsDale]

I think something like this would work:

DAQmxCreateCOPulseChanTicks (_taskCounter, "/Dev1/ctr3", "", "/Dev1/PFI5", DAQmx_Val_Low, 0, 7, 3);

DAQmxSetChanAttribute (_taskCounter, "/Dev1/ctr3 ", DAQmx_CO_Pulse_Term, "/Dev1/PFI1" );

DAQmxCfgImplicitTiming (_taskCounter, DAQmx_Val_ContSamps, 1000);

You can configure the output event terminal to either pulse or toggle, but I don't think you can select how many ticks to count before toggling.

[Kevin_Price]

As Dale S suggested, your further description makes this sound like a good candidate for a fairly simple counter output task.  The default internal behavior of the counter in pulse generation mode is to load low ticks value, count down low ticks to 0, toggle output high and load high ticks value, count down high ticks to zero, toggle output low, etc.   All this happens in hardware, without need for callbacks or reconfig.

Try the method he gave, the key is getting configured so that the pulse generation is driven by "Ticks" of the external pulse signal rather than by an internal timing clock.

-Kevin P 

[zeekial]

Much closer now. Using Dale's suggestion I am now able to output a digital train that waits for 10 low pulses then goes high for 3 pulses and repeats. Unfortunately the pattern is off by one for the first cycle (11 instead of 10, orange input, green output). After the first cycle the 10 low/3 high pattern is as expected. How can I eliminate the incorrect count for the first cycle? 

[Kevin_Price]

Hard to say for sure from just the output.  I'm a little puzzled at the very initial behavior in your screencap.  It appears that the orange input is generally idling high with a brief high->low->high pulse.  However, it looks like its low at the beginning of the screenshot until a single rising transition (not a full pulse).   Also the green output is idling high, seemingly until approximately either the 1st falling edge of the input or the 2nd rising edge.

Now for some educated guesses.  This looks like a test run where you are generating the orange input pulses from a DAQ board.  It's configured for high idle state.  The first transition from low to high is when you start the counter output task, causing the output to change from a board default of low state to the task idle state which is high.  Thereafter, short active-low pulses at a constant rate.

   As to the green output, I'm gonna guess that it's looking for *rising* edges of the orange input signal.  It is also set to idle high, and it starts before the orange task.  No "initial delay" parameter was defined, so the task defaulted to use the minimum, i.e. 2 Ticks.  That's why the first output transition happens at the 2nd rising edge of the input.

Solution: configure "initial delay" to be the same as either your high or low ticks.  Which one you choose will depend on your desired idle state.  I'd be inclined to pick a task idle state that matched the board's default power-up state for the output pin so you don't generate extra transitions on task start or stop.

-Kevin P

[zeekial]

So it turns out the 2 ticks prevents us from creating a pulse at the first edge. Now that we know this we'll determine if we want to move forward with incorporating the functionality for our application.

[Kevin_Price]

Can you describe this in more detail?  This is the first mention I've seen of a need to pulse on the first incoming edge.

-Kevin P