LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Drive analog outputs by edges of pulses

Solved!
Go to solution

Hi, I wanted to generate signals on two analog outputs every time the counter output changes state (both rising edge and falling edge). The pic shows more details:

File_000 (4).jpeg

As you can see, there are four states on the two analog outputs: (0, 0), (1, 0), (0, 0), and (0, 1). The values repeat from the beginning every two counter raising signals, and whenever the counter changes state, the analog outputs would step through those values. 

 

 

My counter output can generate two pulses when an external source comes in, and it is working well. What I haven't figured out is:

1. How to use the counter output as clock source for analog outputs.

2. How to generate a set of analog outputs one at a time whenever the clock edge changes.

ao_counter.png

 

0 Kudos
Message 1 of 6
(2,780 Views)

I would use an event structure.  Two Events: No Change & Counter: Value change  The consumer will then view the counter and current state and previous states to determine the change.  Whenever a rising edge occurs, all analog outputs return to their Low state and whenever the counter falls, either one or the other analog outputs goes to the High state in an alternating fashion.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 2 of 6
(2,769 Views)

I had to do a fairly similar thing before.  My solution doesn't work exactly the way you've described the problem, but it can produce the output you're looking for.

 

AO tasks can't be set up to:

- output on both rising and falling edges of a pulse train

- have two different channels responding to two different clocking schemes

 

Instead, you need to define the AO data buffer to produce your desired pattern based on a much faster pulse train.  The maximum period you can use for this pulse train will equal the shortest AO state, i.e., when both outputs are set to 0.  If the ON times are an integer multiple of this period, you can set pulse train freq = 1/OFF time.  If not, you've got to find the greatest common factor among the times spent in each of the 4 states, and use *that* as your pulse train period.  The reciprocal will be your pulse train freq.

Then you define your AO data buffer to spend the right # of high-freq samples in each state.

 

DAQmx details:

1. Your pulse train config looks generally ok, you'll just need to considerably increase the # of finite samples to generate.

2. The AO task should use the counter output as its sample clock.  If you leave it in finite sampling mode, you should use the same # samples as your pulse train.

3. Use dataflow to make sure the AO task is started *before* the CTR task is started. (This is a general practice -- the master timing task should almost always be started last.)

 

Example:  Let's suppose the time in state (0,0) is 1 msec and the ON times are 10 msec.  You'll have a pulse train of 1000 Hz.  A full cycle of all AO states will require 22 samples - 1 in state (0,0), 10 in state (0,1), 1 in state (0,0), 10 in state (1,0).

   Let's further suppose you want to cycle through the AO pattern 100 times.  You can define both tasks for finite sampling with 2200 samples.  For the AO task, you can either just replicate the 1-cycle buffer 100 times or you can configure the task to regenerate (I *think*.  Maybe not all boards support the combo of finite sampling and regeneration.)

 

 

-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 6
(2,763 Views)

Kevin, I think your method will work. My ON time is actually 9ms and OFF time is 1ms, so I will just re-configure the pulse train with 1ms ON time and OFF time, and repeat the AO values 9 times after the first OFF time.

 

Another question is is there a way to keep my original counter pulse train cause it's the signal that actually determines a camera's ON and OFF time?

0 Kudos
Message 4 of 6
(2,742 Views)

What data acq device are you using for this?

 

One little tweak -- you need the pulse train to have a 1 msec *total period*, so make it 0.5 msec ON time and OFF time.

 

You *can* recreate the original pulse train with 1 msec high and 9 msec low, but a little more tweaking is involved.  You'd *want* to drive it off the 1 kHz pulse train and define 1 cycle high and 9 low.  But you can't.  You need a minimum of 2 timebase edges for each pulse interval.

  Thus, you'd need to run the 1st pulse train at 2 kHz, use it to drive a 2nd one with 2 cycles high, 18 low.  You'll also double up your AO buffer values to be 2 samples off between each channel's 18 on.

 

 

-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 5 of 6
(2,729 Views)
Solution
Accepted by topic author joehsiao

Kevin, I got it working by keeping the counter signal the way it was, and wiring counter output to PFI1, and make the AOs triggered by rising edges of PFI1. When AOs sees the first rising edge (there will be two, but AOs will be in the middle of outputting and thus ignore the 2nd one), they would output 20 predefined values in units of 1ms.

 

BTW I am using a PCI-6723.

Here is the final vi and a pic of signals from counter output and AO2.

ao_counter.pngFile_000 (5).jpeg

0 Kudos
Message 6 of 6
(2,702 Views)