LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQMx - two counters, one inverse of the other

I have an NI USB-6363. I have a need to use two counter outputs, where the second counter is low when the first counter is high. The frequency ranges from 200 to 500Hz. I also need to switch counter 2 to be in sync (high when counter 1 is high) at the switch of a boolean control on the front panel. I am new to DAQMx and unsure of the best approach to do this. Some idea are:
1. Set idle state of counter 1 to high, and idle state of counter 2 to low.
2. Use a digital output hardwired to a digital input and use that input to trigger the second counter. I could put these in a loop along with a DAQMx counter write instruction?
3. User Immediate Routing to tie counter one to counter two with a logical invert?

Thanks in advance!

^TeraTech.

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? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 1 of 13
(3,283 Views)

 

Here's how I see it:

 

1. setting counter 2 idle state opposite counter 1 will help give you a reverse polarity.

   Caution: I think I recall that once upon a long time ago, the "low time" and "high time" behaved opposite to my expectation when I set idle state to non-default.  I *think* that "low time" actually ended up meaning "time spent in idle state" while "high time" meant "time spent in non-idle state".  Hopefully that's all been ironed out over the course of newer boards and driver versions, etc.  Just be sure to check this out so you know for sure how it'll behave.

 

2. the polarity cannot be changed on the fly while the counters are running and generating pulses.  You'd need to stop, reconfigure, and restart counter 2.

 

3. syncing the timing of the counters depends on them both starting on the same start trigger signal.  Thus, if you stop counter 2 to reconfig idle state, you'll also have to stop counter 1 so you can restart both and generate the trigger that syncs them.

 

4. If it's a problem to have to stop and restart the pulse trains, you could instead handle all of this stuff by using an external logic circuit.  Either an invert with an enable input or a direct XOR circuit would work.  You could just feed counter 1 output to the circuit.  Then just toggle a digital i/o bit to toggle the behavior of the external circuit.

   This will happen on the fly without needing to stop the pulses.  You also won't need to use counter 2 anymore.  You'll have the native counter 1 output and the circuit output whose polarity can be toggled at any time.

 

 

-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 13
(3,269 Views)

Thanks. Starting and stopping the counters is not a problem. So it seems 3. syncing the timing of the counters is the cleanest approach. I can't seem to find any examples of Immediate Routing with two counters.

^TeraTech.

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? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 3 of 13
(3,257 Views)

I had the same problem and found a very simple solution: I just use a route with the  source the output of one counter and as the destination another terminal and set the invert to yes. You even need just one counter in this case.

 

Christian

0 Kudos
Message 4 of 13
(729 Views)

What device that that inversion work on?   I tried it on several common simulated devices (M-series, X-series, TIO-series) which all gave an error that the hardware didn't support the inversion option.

 

 

-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 13
(720 Views)

Hm, seemingly the Simulation is not perfect :-). It works on a NI USB-6210 that I use for test purposes. Next, I will test it on a 6612. 

 

Christian

0 Kudos
Message 6 of 13
(706 Views)

Now also tested on a 6602. Seems to run, no error messages. LV20 code enclosed.

 

Christian

0 Kudos
Message 7 of 13
(693 Views)

@cghuebner wrote:

I had the same problem and found a very simple solution: I just use a route with the  source the output of one counter and as the destination another terminal and set the invert to yes. You even need just one counter in this case.

 

Christian


Hi Chistian, I'm the OP. I understand routing can be done but had originally considered routing one counter to another. Remember that in my original post, I needed 2 counter outputs so, I'm unsure exactly what you are describing. You're routing for instance CTR0.SRC to CTR0.OUT, then using the SRC pin as one output and the OUT pin as the other counter output? Can you post a LV2017 version of your VI?

^TeraTech.

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? (Check out this lengthy post of mostly complaints)
0 Kudos
Message 8 of 13
(691 Views)

The best I can tell from the "Device Routes" tab in MAX, connections from one PFI terminal to another show up in yellow, which typically means that a counter is consumed to accomplish the connection.  So you use one counter explicitly for pulse generation and another counter implicitly to route the pulse to another terminal by way of another counter, with the option to invert it along the way. 

 

So perhaps one might be able to change the inversion property on the fly as a neat solution to the OP's problem.  Start out inverted and then change to non-inverted when the user toggles a GUI boolean.

 

Sorry, can't test as the simulated hardware doesn't give a reliable indication about feasibility.

 

 

-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 13
(679 Views)

I simply route one counter out (the PFI I defined as the output terminal) to another PFI line and set invert to yes. Enclosed the VI and a screenshot from my settings plus from the scope.

0 Kudos
Message 10 of 13
(659 Views)