X series routing counter output to PFI8 (ctr0A)

[johndoe777777779]

Hi,

I am using x series 6368 board, and would like to use the PFI8/P2.0 pin for counter output. To test this, I output a 500kHz square wave using the counter1. I then connect the counter1 InternalOutput to PFI8. After running the code, the output on PFI8/P2.0 pin is a square wave with levels +/-0.5V. The normal waveform is supposed to be between 0V and 5V. What can I be doing wrong? Here is my code used for this task:

    DAQmxCreateCOPulseChanFreq(taskHandle, "Dev1/ctr1", "", DAQmx_Val_Hz, DAQmx_Val_Low, 0.0, 500000, 0.50)
    DAQmxSetCOPulseTerm( taskHandle, "Dev1/ctr1", "/Dev1/PFI8");
    DAQmxConnectTerms("/Dev1/Ctr1InternalOutput", "/Dev1/PFI8", DAQmx_Val_DoNotInvertPolarity)
    
    DAQmxCfgImplicitTiming(taskHandle, DAQmx_Val_ContSamps, 100000)

    # DAQmx Start Code
    DAQmxStartTask(taskHandle)

Thanks.

[johndoe777777779]

Some additional information:

The pin PFI 8 connects to "CTR 0 SRC " and "CTR 0 A" by default.

If I route the counter output to PFI 9 or PFI 10, the waveform comes out fine (500kHz square wave, 5V amplitude). But when the counter output is routed to PFI 8, there is a 500 kHz square wave between -0.5 V and 0.5 V. It seems the pin needs to be disconnected from "CTR 0 SRC " and "CTR 0 A" but not sure how?

[Kevin_Price]

Don't have an answer, just a confirmation that what you're seeing is unexpected & worth some investigation.

It's very normal to be able to route a counter output to any of the PFI pins and then have another counter reference that pin as an input signal (for edge counting, sampling, triggering, etc.)   I often do that without measuring the output signal on a scope, but I do see that the input counter task responds to the signal properly.  That at least *implies* a normal TTL voltage range.

Is it possible you have a DIO task configured for that same pin?   The only other thing I see is your use of "DAQmxConnectTerms".   I'm a LabVIEW-only guy so I don't really know the text language syntax, but this sounds like a *different* kind of routing than the kind I virtually always do.  I don't really think that should be a problem, but it's one more thing to consider.

Your kind of routing happens without reference to a task and thus it remains persistent long after the task is done.  I usually don't want want that so I use task-based routing.  I believe the function has a name like DAQmx Export Signal.   This kind of routing only persists as long as the task runs (plus a little longer to let cleanup and garbage collection happen).

-Kevin P

[johndoe777777779]

Hi Kevin,

Thanks for the response.

1. I don't have a DIO task in this program (or running concurrently).

2. To debug the issue, I tried the function you suggested: DAQmxExportSignal. It has the same result: it works on PFI 10, but shows +/-0.5 V signal on PFI 8. (BTW I need to use DAQmxConnectTerms because DAQmxExportSignal has a set of signals it can export, while the former gives more flexibility in frequency, duty cycle, and delay of the signal).

Thanks,

[Kevin_Price · Accepted solution]

So it sure seems that there's something electrical going on to change your 0-5V pulse train that way.  Is anything physically wired to the PFI8 terminal?   If so, disconnect everything there and try again.  Otherwise, can you solve the immediate issue by choosing to output your pulse train to a different PFI pin?  The default output pin for Ctr1  that needs no special routing is PFI13 (a.k.a. pin 40 or DIO 2.5).

It's premature to conclude board damage, but if it *does* turn out to be that then you should carefully consider whether some past external connection may have caused the damage *and* whether that event may have caused damage to other inputs.

Meanwhile, I looked a little closer at your config code.  The line:

DAQmxSetCOPulseTerm( taskHandle, "Dev1/ctr1", "/Dev1/PFI8");

*is* the kind of task-based routing I was referring to.  Just that line should be all you need.  You can comment out the following line because it shouldn't be needed: 

DAQmxConnectTerms("/Dev1/Ctr1InternalOutput", "/Dev1/PFI8",...

 While I'd be surprised if removing that line helped with your immediate problem, I couldn't personally entirely rule it out since I don't much familiarity with that kind of non-task-based static routing.  

-Kevin P

[johndoe777777779]

OK, thanks for pointing to possibility of hardware problem. It was just a weak connection at this pin on my board. The output is working now on PFI 8.

Also the code

DAQmxSetCOPulseTerm( taskHandle, "Dev1/ctr1", "/Dev1/PFI8");

seems to be working now.

Initially I was not getting the result (probably the bad connection at PFI8) and started using the DAQmxConnectTerms function.

Thanks for your helpful responses.