Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counting output pulses

Solved!
Go to solution

Hi all,

 

I’ll precursor all of this by saying I’m not particularly experienced with DAQmx and NI instrumentation, so please bear with me and feel free to point out anything obvious you think I may have missed, as I probably have.

 

I’ve got an NI-6036E multifunction DAQ card and I want to generate various pulse trains whereby I know exactly how many pulses have been generated. However, I’m having trouble devising a way of accurately generating a pulse whereby:

  • The number of pulses to send is known before the task is started
  • The task may be interrupted before it finishes
  • Pulse frequency will vary from 0Hz - 1kHz

I’ve attached some example code I’ve put together that almost does work as well as I need it to. I’ve set up Counter 0 as a continuous pulse output and it’s pause trigger is set to the internal output of counter 1. Counter 1 is set to edge count, and its edge count terminal is set to Ctr0InternalOutput. By reconfiguring Counter 1 initial count and setting it to count down, the pulse generation task then pauses on Counter 1’s terminal count event and the number of generated pulses is counted throughout.

 

The problem I’ve got though, is that the hardware set up I’m interfacing to is expecting counter 1 to generate the pulses. When I set up Ctr1 as the pulse generator and Ctr0 as the pulse counter in my attached example, I get errors about hardware routes not being supported for setting Ctr0’s edge count terminal as Ctr1InternalOutput. I assume this is a restriction of the NI-6036E hardware as the same code runs without error on other NI DAQ cards.

 

Is there something else I can do in software to achieve the result I am after? Perhaps by designating different pins or using a different method? I really don’t want to modify the hardware setup for (my) software shortcomings but will if I need to.

 

Many thanks,

James

0 Kudos
Message 1 of 8
(3,731 Views)

Have you looked at the shipping examples?  There are much easier ways to generate a finite pulse train with a fixed # pulses.  It's one of the basic feature sets under DAQmx.  Here's how it looks:

 

finite pulse train.png

 

 

-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 8
(3,703 Views)

Hi Kevin, thanks for responding!

 

I have looked at those examples and I'm happy generating a finite number of pulses, as shown in your snippet. 

 

The problem I have is that my pulse task could be stopped before the set number of pulses is complete and I need to have an accurate count of the number of pulses that were sent.

 

Is there a way to do that with a counter output task set to finite samples?

0 Kudos
Message 3 of 8
(3,689 Views)
Solution
Accepted by topic author developer_error

Unfortunately, no* there isn't.  I now have a better understanding why you were trying the approach you described originally though.  For someone self-described as inexperienced with DAQmx and NI devices, that's a pretty clever and sophisticated use of the counters!

 

In MAX, if you select your device there will be a tab on the bottom right called "Device Routes".   This will show you the legal direct and indirect routes that can be configured.  Caveat: the yellow indirect routes nearly always need to consume an available counter.  On older boards like yours, they may need to consume a *specific* counter.  Since your app requires both counters, you'll need to limit yourself to the green direct routes.

 

What I see from adding a simulated device is that Ctr1InternalOutput can be directly routed to be the AO Sample Clock, the Ctr0Gate, or the (default) Ctr1Out pin.  That's not much to choose from, but let's see if we can make AO work, assuming you aren't already using it.

 

With Ctr1 configured as a simple finite pulse train (like my earlier example), AO would be configured to use Ctr1InternalOutput as its sample clock.   I would configure the AO task for Continuous Sampling to make sure the task is still running and active at the crucial moment ahead of us.

    Use DAQmx Write to write a bunch of 0 values into the AO task buffer.  Write more values than the # pulses you intend to generate.  Then make sure you start the AO task before starting the Ctr task.

 

Once the pulse train finishes, or if you stop it early, you should be able to query the AO task for the DAQmx Write property "Total Samples generated".  That should be a count of actual pulses generated.

 

 

-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).
Message 4 of 8
(3,661 Views)

I know what I've ended up doing might look sophisticated but trust me - it took me a long time to get there! I have been looking at the device routes, but I can't make much out of them at the moment. I certainly would have never arrived at your proposed solution.

 

That's an interesting one and I don't see why it won't work. We are performing some AO on the card but the actual AO values don't need to be updated whilst the pulses are being generated.

 

Having just had a quick google, it appears that the state of the analogue outputs is maintained after the task is stopped. So I think I can implement your suggestion but I'd have to do some juggling by stopping the AO task and changing the clock before generating pulses. Then I'd just have to write 0 to a dummy AO channel before stopping the task and putting the clock back.

 

I'll have a go when I've got the hardware again next week, thank you!

0 Kudos
Message 5 of 8
(3,642 Views)

A couple quick followup thoughts for making this AO idea work.

 

1. Only one hw-timed buffered AO task can run at a time on your device.  (This remains a typical restriction for desktop devices,)   But you're right that the AO output voltage will be held after you stop the task.

 

2. This special task can either use a dummy AO channel as you mentioned, or you could just keep generating the existing voltage value on your active AO channel.

 

3. You should be able to define and configure 2 distinct AO tasks -- one related to normal use, one related to this special purpose use.  You just can't run them both at once.   As long as you stop the running task first, you should then be able to start the other pre-configured task.  And vice versa when it's time to switch back.

    I *think* (but am not 100% sure) that the pre-config can include writing data into the task buffer.  But it's possible you'd have to save the write until just before the start.

   You don't *have* to pre-configure them, but it will be a little more efficient.  It might also more convenient for your code, though then again it might not.   Just trying to keep you aware of options.

 

 

-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 6 of 8
(3,631 Views)

Nevermind idea #3 above.  I got to having some second thoughts and tried it out with a simulated device.  Merely stopping one task didn't allow the other to be started -- resources reserved for the buffer of data aren't released until the task is cleared.  And once you clear it, you'd have to recreate a new one next time.  So there's no advantage in trying to preconfigure the 2 distinct tasks after all.

 

 

-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 7 of 8
(3,627 Views)

Just as a follow up, I drafted up some code using your suggestions and successfully tested it, so thank you very much for your help, Kevin!

0 Kudos
Message 8 of 8
(3,597 Views)