Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Terminal count is reached for counter Input task

http://forums.ni.com/t5/Multifunction-DAQ/Can-6014E-generate-an-interupt-when-the-terminal-count-is/...

I have found above and need assistance to generate toggle at output pin of counter when terminal count is reached. I opened two NI MAX, and use one to generate a counter input task with initial count as 5, counting down direction. Use another NI MAX to monitor the output pin (PFI12 for Ctr0 in my case). I have supplied an external contineous pulse source to the source pin of Ctr0. I would expect to see a pulse or toggle at the output pin of Ctr0 when the count rolls over zero. However, there was no signal generated at output at all and I have verified that with a oscilloscope. It remains the same scenario when I set a large initial count and counting up. Could anyone help in addressing how I can program the counter to output a pulse (or toggle) when TC is reached using DAQmx and how I can set up a simple test to pick out Terminal Count? By the way, my card is PCIe-6363.

Thank you.

 

0 Kudos
Message 1 of 11
(5,662 Views)

I don't know the text-based coding syntax, but here's a snippet of LabVIEW code that worked, with some explanation following.

 

pulse on tc.png

 

The middle section most closely relates to your question.  That's the counter that'll count down to TC, generate an output pulse on a PFI pin, then reset itself back to initial count to do it all again.   The upper counter just generates a slow clock signal so I could observe the behavior at human speed.  The lower counter simply counts the # of TC pulses it observes on the chosen PFI pin.

 

The main thing you probably need is the middle "DAQmx Export Signal" code.  You just define a PFI pin as the output terminal and configure the task to create a full pulse when it reaches TC.  (The other option is to toggle state, which is usually less helpful when interfacing to other stuff.)  You need to explicitly export the internal "CtrOutEvent" signal to a specific physical terminal because the normal default behavior for an input task would *not* include making output signals.

 

The middle "DAQmx Channel" code is mostly concerned with setting up the "count reset" behavior, assuming you'd like to countdown from 5 repeatedly.  Once you countdown to 0 and generate a TC pulse, that same pulse resets the countdown counter back to 5.  This can repeat forever.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 11
(5,623 Views)

Thanks for reply and I've actually carried the middle part out in text-based DAQmx as below:

 

DAQmxCreateCICountEdgesChan(taskHandle, "/Dev1/ctr2", "", DAQmx_Val_Falling, 5, DAQmx_Val_CountDown);

DAQmxSetCICountEdgesTerm(taskHandle,"","/Dev1/PFI0");

DAQmxSetExportedCtrOutEventOutputTerm(taskHandle,"/Dev2/PFI14");

DAQmxSetExportedCtrOutEventOutputBehavior(taskHandle, DAQmx_Val_Pulse);
DAQmxSetExportedCtrOutEventPulsePolarity(taskHandle,DAQmx_Val_ActiveHigh);
DAQmxSetExportedCtrOutEventToggleIdleState(taskHandle,DAQmx_Val_High);
DAQmxTaskControl(taskHandle,DAQmx_Val_Task_Reserve);
DAQmxStartTask(taskHandle);

 

I am using an external function generator with 2 Hz pulses, and an oscilloscope to look at this source as well as the output of the counter. However, it generate a pulse everytime it sees the edge from the source, not just reaching target count of 5. Is it related with my card, PCIe-6363? But it's hard to believe since it seems to be a basic task it should be accounted for.Any idea?

0 Kudos
Message 3 of 11
(5,619 Views)

A typo in the last post:

DAQmxSetExportedCtrOutEventOutputTerm(taskHandle,"/Dev1/PFI14");

0 Kudos
Message 4 of 11
(5,610 Views)

Hmmm, I don't see anything obviously wrong.  I didn't have a scope to look at my signals directly, that's why I used another counter to watch for and count the TC pulses.  My recollection (from quite a while back, but I'm *pretty* sure...) is that a TC pulse has a fixed width that's 1 or 2 cycles of the board's default timebase.  I'd venture it ought to be about 50 nanosec for you.  Are you seeing that kind of extremely brief pulse?  Or are you seeing something that looks more similar to the ~2 Hz function generator square wave?  The only thing I'd suggest trying is to comment out the line for setting ToggleIdleState, the driver may not like being configured with both pulse and toggle polarity settings.

 

[time passes...]

Ok, I just modified my little example to measure the TC pulse width and was kinda surprised by the result.  The pulse width was much wider than I had expected.  A little experimenting showed that the pulse width would always equal 1 full period of the source signal being counted.  It *isn't* 1 period of the board's internal timebase as I'd previously thought.

 

However, I can definitely confirm that the TC pulse only happens once each time I countdown to 0, not once each time there's an input source signal edge.  I'm using a PCIe-6341.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 11
(5,599 Views)

I have tried again by getting rid of ToggleIdleState, but it still not just outputting at TC. The pulse width is consistent and wider than 1 period of internal timebase.

Have you tried with NI MAX by creating a counter input task? As I described in the first post, I cannot see any output signal when counter value rolls over. It is different from that done by using DAQmx.

I will try more and update if anything new comes up.Thank you.

0 Kudos
Message 6 of 11
(5,595 Views)

Does the TC pulse width vary with the function generator frequency?  In my test program, it did.  The width was 1 cycle of the square wave coming in.

 

I wouldn't expect the test panel for edge counting in NI-MAX to produce a TC pulse.   That's a non-default special behavior, which is why we need calls to "Export" the CtrOut signal.  It wouldn't happen otherwise.

 

Unfortunately, no other ideas why you see pulses when counting down but before reaching 0.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 7 of 11
(5,579 Views)

Thank you for your answer. I think TC pulse width vary with the clock used, and will try more later to see if anything new to update.

 

I am having another question, and I can create a new post if necessary. Now I have an analog output task which is set to be hardware retriggerable by a PFI line. This AO task is using finite sample clock. However, I would like to be immediately noticed when it was being triggered. Is there a simple event that I can register to?

Since I am using finite sample clock mode, I cannot use HW single point. I am thinking to use another task for this.

"Change detection event" is available with my card. Can I use another DI task to look at that PFI line and register the change detection event for the triggered notice? But the "change detection" needs two lines, instead of one, right?

Basically, I want to find out what is the most efficient way to be noticed when AO task is being triggered (first time or every time). Thank you.

0 Kudos
Message 8 of 11
(5,568 Views)

Can't fully vouch for this as I'm just poking around api looking for options.  This isn't something I've actually done, but it appears it'd be a possibility.  Ok, caveat aside, here's what I'd aim for:

 

DAQmx can be configured to generate certain kinds of "events".  In text programming it's probably something like an interrupt pointing to a callback function.  In LabVIEW, they get handled much like various Windows GUI events.  If you opt to use the "Change Detect Event", it can only originate from digital port 0 of your boad.  The consequence is that you'd need to physically wire from the PFI pin to a DI pin, and you wouldn't be able to do any other kind of timed DI.  You don't need 2 DI lines but you do need the 2nd wire to get from the PFI pin to a DI pin.  Another option is to use a "Counter Output Event" while configuring one of the counters to generate a retriggerable single pulse, triggered off the PFI pin.

 

Note that you can't combine finite sampling AO and hardware timed single point AO on the same board.  All hw-timed AO must be timed the same way.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 11
(5,545 Views)

Thank you for your responses Keven_Price, they have been helpful.

 

I do have one question about the middle counter. On the right side, DAQmx Export Signal has two properties. CtrOutEvent.OutputTerm and CtrOutEvent.OutputBehavior - Pulse. In my C code when I try and set an output behavior I get an error that I can not have both an input, CI Cnt Edges, and a CO on the same task. But it appears you do. I am writing in C and have never used labview so I might be missing something.

 

The goal is very similar to skuo1008, I am taking an external signal 10MHz, and using a counter to divide the signal down. Every time the counter hits zero I want the counter to reset to the initial value, then count down again. When zero is hit, I need the callback function to be called.

 

Currently, the counter is resetting to zero and calling the callback function the first time it hits zero, then again some time later but the counter is past zero when it resets. This second reset does happen consistantly at the same spot but not when the counter is at zero. 

 

Using the PCIe-NI6612 card.

Thank you

0 Kudos
Message 10 of 11
(5,088 Views)