Pulse Train Generation not Working

[uhuzaifa]

Hi there,

I have a PCI 6229 DAQ installed in my PC and I am accessing it using the SCB-68A breakout board. I am struggling with generating a Pulse Train using either of the counters on-board. Here is how I have tried it:

• Using the Test Panels in NI MAX, I have tried to Counter Output on CTR0OUT (PFI12) and CTR1OUT (PFI13) without providing any signal to CTRxTRG or CTRxSRC pins. Checking by connecting an oscilloscope probe between CTRxOUT and DGND, I get no output. I am using the default values for Frequency (1000 Hz) and Duty Cycle (50%).
• Using NI MAX, creating a task CouterOutput is of no use either. Choosing either of the counters in Continuous Pulses with 1000 samples, gives nothing. Other options have been explored in this task too but to no avail.
• I have successfully tried other functionalities of the board such as Analog Output, Edge Counting (using either of the counters), so there is something wrong only with the Counter Output.

Could it be that my assumption of Pulse Train being RSE is wrong? Am I trying to measure it correctly? Or do counters require triggers to generate output?

Looking forward to useful directions.

[Kevin_Price]

You mentioned RSE, which I've only known to be a terminal configuration for *analog* tasks.  There's nothing related to RSE available in the MAX test panels for counters.

Since there appears to be confusion on *that* point, I'm left to wonder if there just might be some confusion mixed into the rest of what you described.

Let's try the shipping examples instead of MAX.  Open the one for continuous counter output (not buffered).  Configure it for CTR0, 1000 Hz, 50%, and to use PFI12 as its output terminal (which you've reported as the default).  Then run it.

First check with your scope again.  Assuming you get nothing, let's proceed to a semi-internal check.

Open another shipping example for counting edges (no clock).  Configure it for CTR1 and count edges on PFI12.  Run it.  Is your count increasing at about 1000 counts/sec?

If not, we'll move on to a totally internal check.  Right-click the 'Input Terminal' GUI control and choose "I/O Name Filtering...".  Then check the box to include advanced terminals.   Click OK then use the drop down to select the terminal name "/Dev1/Ctr0InternalOutput".   (Note: substitute your actual device alias in place of "Dev1" if necessary).  Run it.  Now is your count increasing at about 1000 counts/sec?

-Kevin P

[uhuzaifa]

Thanks for clarifying RSE. But my testing was not reliant on this point. 

I am unclear about the shipping examples. Are these examples in LabVIEW? I want to try without it (dont have it, and want to use the DAQ with MATLAB or Python).

[Kevin_Price]

I'm afraid the shipping examples I was referring to *are* in LabVIEW.  That's the most common language used around here so I guess I just assumed.

I don't have detailed knowledge about using any text-based DAQmx API.  I know that *some* examples exist, but I've gathered that it's not nearly as thorough and extensive a set as offered in LabVIEW.

PFI 12 & 13 will also be accessible as digital lines -- looks like port 2, lines 4 & 5.   Maybe you can test those pins in MAX when configured for digital input and output rather than for counter operations?  To me, it seems very likely that if those pins respond as DI and DO, then they ought to work for your counter as well.

-Kevin P

[NPowl]

Heya,

I just want to check two things:

1) When we're using the default PFI lines for ctr0/ctr1, are we changing the Pulse Terminal at all? 

2) Are you able to pull up NI IO Trace, track NI-DAQmx calls and start the Counter pulse generation?  

We should see the Trace call out the creation of the task, channel and the other API calls before closing. I don't have a real PCI-DAQ with me at the moment but my simulated device calls these:

Finally, there's a quick example code in Python at the bottom of this KB - can we try this out? 

Cheers,

Nick