counter output high when should be low

[Skydyvr]

I'm trying to set up a program which uses the two counters on my USB-6251. What I would like to do is set up a variable pulse width and frequency - hence the use of the counters. I want to sequentially pulse the counters. When one counter is pulsing, I want the other counter in the off state (outputting 0V). And then I want to pulse the other counter and the first counter will be at 0V. I have started with the counter - finite output.vi example and quickly modified it to attempt what I am trying to do. However, whenever I start a task, the counter that should be off turns to a constant 5V state - See capture.png. It happens on both sides. How do I prevent the counter that I am not actively pulsing from being driven high? I have no other circuitry attached to the DAQ. Just the output from my USB-6251 going into two channels of my o'scope.

[Bob_Schor]

I'm not familiar with your device, but I've seen other NI Digital Output devices be (shall we say) somewhat "ambiguous" before being set to 0 or 1 -- depending on the circuitry of the output stage of the device and the circuit to which it is connected, when first powered up, it might not necessarily be at 0.

Try, as part of your initialization code, to set all of the digital outputs to 0.  See if that fixes your problem.

Bob Schor

[Skydyvr]

Thanks for the reply, but that is not what is happening with my device. You can see in the "Capture.PNG", that the output is low before the pulses begin. I didn't show the whole pulse train as I was trying to zoom in to what I thought was important. But at the end of the pulse train, CH 1 (yellow) goes low when CH2 (blue) stops pulsing. Then you transition to the right picture and both outputs start out low and as soon as CH1 starts pulsing, CH2 goes high. This is not an initialization problem because the right picture is taken after the left picture in the sequence of my LV program.

I am starting to believe that there is a serious problem with the digital (counter and PFI) outputs on the USB DAQs (6251 variety). I rewrote my program to use only 1 counter and just toggle it between 2 PFI outputs. The NI hardware does not function correctly allowing the signal to route to only the correct output selected. It routes the signal to the first selected output but then when I want to route it to the second output, it routes the signal to BOTH outputs - not just the second one. And it will not go back to routing to just a single output until the hardware is power cycled! But then again for only a half cycle.

It just makes it impossible to use (this) NI hardware to simulate a Half-bridge controller.

[Kevin_Price · Accepted solution]

The first issue is normal behavior for M-series (and earlier) counter types.  Finite pulse trains are defined and configured by referencing the counter which generates the pulses.  But under the hood, the neighboring ("paired") counter is *also* used to generate a gating ("pause trigger") signal of the right duration to control the exact # of pulses to be generated.   The scope is showing you that precisely-timed pulse from the paired counter.

There's a likely workaround for it.  You'd have to do more grunt work, but the essential ideas are:

- the paired counter is configured for a single pulse.  The duration should exactly accomodate the desired # of pulses from the main counter.

- the main counter is configured for continuous pulses.  It also is configured for pause triggering, using the internal output of the paired counter output as the pause trigger signal.

- a special step is needed on the paired counter config.  You can explicitly designate an output terminal for the pulse, and if you wire in an empty string, then the internal signal is not routed out to a PFI pin terminal.

- your code would need to monitor for when the paired counter's pulse completes, that's when you'd know to stop the main counter task.

For the 2nd issue, I'd first recommend using task-based routing rather than the direct DAQmx Connect Terminals API that defines source and destination terminals but has no task refnum input.  You might already be doing that, so the 2nd suggestion is to search for "lazy uncommit".   Spoiler: there may not be a clean method within your power to prevent the issue.

-Kevin P