From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

NI 6211 ramp signal and two counters generating

Solved!
Go to solution

HI All,

I would like to use my NI 6211 to generate the following three signals as the following pic shows.

Capture3.JPG

my current problem is I have no idea how to sync my pulse with another two counters. I have attached my VI to this post. And any suggestions would be appreciated!

0 Kudos
Message 1 of 5
(2,454 Views)

to be clear, I used two different physical channels in NI 6211 to generate two different counters (pulse and clock).

Again have no idea whether this is the right way to do it or not. Or I should have a trigger setting in the retriggerable mode to realize it. 

0 Kudos
Message 2 of 5
(2,450 Views)

Not enough info given.  Please describe the needed timing and causality relationship among the signals.  I have a best guess, but it's just a guess at this point.

 

It's pretty clear that the AO will regenerate the asymmetric triangle waveform.  Presently it uses the "Clock" pulses as a sample clock.  However, it isn't clear to me why you need to generate the "Clock" pulse train using a counter task because the AO task could make its own sample clock.  If something else needs this signal, it could be exported from the AO task to a PFI terminal pin.

 

As to the "Pulse" signal, that appears to occur once per 540 Clock pulses which is the same as once every 540 AO samples.  What isn't clear is whether it should *trigger* a cycle of AO samples or whether it should pulse to indicate something like "done-ness" of an AO cycle.  In other words, are you looking to react to it or cause it?

 

 

-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 3 of 5
(2,426 Views)

Thank you for your reply, Kevin.

'However, it isn't clear to me why you need to generate the "Clock" pulse train using a counter task because the AO task could make its own sample clock.  If something else needs this signal, it could be exported from the AO task to a PFI terminal pin.'---The pulse is used to send to the frame grabber as to notify it 'this is the start of one frame'. The clock signal is used to send to a horizontal scanner, notifying it 'this is the start of one line of each frame (540 lines per frame)'.

As to the causality relationship, the pulse signal should trigger the clock, but both signal starts at the same time.

Hope it clarify my situation.

0 Kudos
Message 4 of 5
(2,351 Views)
Solution
Accepted by topic author Penny001

Both diagram and code suggest that you want a continuous AO task that keeps repeating the same triangle.  That part's straightforward enough and the code seems like you've got a good start.  You just need a more graceful exit strategy than a 10000 sec timeout.

 

Then I think you only need one counter to act as the trigger and frame pulses.  The AO task can make its own sample clock and then export it to a PFI pin for use by your horizontal scanner.

 

Here's how it'd work:

1. You need to establish a true 540x relationship between the AO sample clock and the frame clock rate.   The easiest way would be to define the frame clock in terms of dividing down the AO clock.  You can't do it that way though because you need the frame clock to *trigger* the AO task, so it needs to happen first.

   My suggestion: configure the AO task first.  After configuring a *requested* sample rate using DAQmx Timing, query a DAQmx Timing property node to find out the actual sample rate.  The reason they're *sometimes* different is that only certain discrete frequencies are physically possible based on dividing down an internal timebase by various integers.  Sometimes DAQmx is stuck having to use a neighboring integer divisor, leading to a slightly different sample rate than that requested.

   Once you've determined an actual AO clock rate, you can divide it by 540 and know that the corresponding frame pulse rate will be physically possible.  (Dividing freq by 540 means that the integer divisor gets *multipled* by 540, which definitely leads to another integer).

 

2. Configure the frame pulse task for continuous pulses at 1/540th the AO rate.  Don't start it yet.

 

3.  Configure the AO task to use the frame clock as a Start Trigger.  Also configure the AO task to export the Sample Clock signal to a PFI pin (for use by your horizontal scanner) using the function "DAQmx Export Signal.vi".  Start the AO task *before* starting the frame pulse task.

 

4. Start the frame pulse task.

 

That kind of approach ought to produce the right timing relationship among the 3 signals. 

 

 

-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 5
(2,341 Views)