When using counter 0 output, counter 1 goes to high state

[JFoor]

I'm using a PCI-6229 DAQ card with LabView 7.1.  Running the pulse generation example VI called "Gen Dig Pulse Train-Finite.vi" (located in the Counter\Generate Pulse library), I noticed the following anomaly. 

If you select dev1/ctr0 as the specifed counter for the DAQmx Create Virtual Channel CO Pulse Freq VI, and also select a given frequency, idle state, duty cycle, and number of pulses, the output on counter 0 (pin2) will indeed output the correct pulse train.  However, during this pulse train, the output on counter 1 (pin 40) goes high.  This also occurs vice versa (if dev1/ctr1 is selected, counter 0 output goes high during the pulse train on counter 1 output).

Thus, it appears the counter outputs cannot be used simultaneously.  If one is used to generate a pulse train, the other will go high and vice versa.  Is this by design?  Is there a way to get around it?  I can't find anything in the literature. 

[Kevin_Price]

What you see is in the nature of how DAQmx manages finite pulse train generation.  It actually uses 2 counters, where one of them is used to generate a single, hardware-timed "gating pulse" which controls how long the other counter's pulse train is generated, thereby also controlling the # of pulses generated.  As an experiment, try performing continuous pulse train generation -- you'll see that the other counter no longer sends its output high.

Workarounds?  That depends.  I'm not near LV or hardware to experiment, but I *think* I recall reading a thread one time that discussed how to prevent an output pulse from being routed out to the terminal block pin.  However, I'm not sure if that same technique would allow you to suppress the gating pulse in a finite pulse train generation.  Ah yes, here's that posting. 

If you can't suppress the gating pulse directly via the finite pulsetrain task, there *are* old-school ways to generate finite pulsetrains which should give you the ability to use the linked technique.  You would configure for continuous generation but use the gating counter as a "pause trigger."   You would also generate a single pulse with the gating counter after calculating the exact pulse width needed for the # pulses you want.  After the single pulse task is done, you'd stop the continuous pulse train task.

-Kevin P.

[Paul_C.]

Hi JFoor,

Kevin is correct and this is due to the fact that generating a finite pulse train requires the use of both counters. I'm not sure about the suggestions made in regards to a workaround.  You could generate a continuous pulse train (which requries only the use of one counter) and use software timing to generate a finite pulse train (basically turning the counter on and off).  This would be less accurate, but depending on the frequency you're outputting, it may meet the requirements of your project. 

I hope this helps,
Paul C.


Message Edited by Paul C. on 11-27-2007 12:35 PM