finite pulse train with different frequency

[lxx]

Hello,

I'm trying to modify the labview example "generate finite pulse train" to generate a finite pluse train with different frequencies. Each freq will run 400 pulses. The freqs are stored in an array, which is being fed into a for loop. Thus ramp up the freq each iteration. However the program only generate 400 pluse at first given freq. I'm fairly new to daqmx and not sure what is wrong. Anyone have some idea how to fix it?  

[Kevin_Price]

The best "fix" will depend a bit on the needs of your app.

Is it ok to have a fraction of a second without any pulses each time you change frequencies?  If so, then there's a pretty simple solution:

1. Outside the loop you'd create a DAQmx virtual channel and configure for Finite Sampling (# samples = 400) using DAQmx Timing.vi.  

2. Inside the loop you'd chain together a DAQmx Channel property node where you set the pulse frequency property, then perform a DAQmx Start, a DAQmx "Wait for Task Complete", and a DAQmx Stop.

3. So for each freq in your array, you'll program the counter for that frequency, start the generation of pulsetrains, and then stop the task after 400 pulses have been generated.

If you must change frequency on-the-fly, producing *exactly* 400 pulses at each freq setpoint will be tricky, and maybe even impossible to do reliably.  Some techniques will get you closer than others though, so post back if you need to do this.

-Kevin P.

[lxx]

Kevin,

Thanks for the reply. I have tried your suggestion. Like your said, there is indeed an small delay between each iteration. Unfortrunately, I do need to change the frequency "on the fly" and produce a specific number of pulses at the same time. I wrote a program that can take the freqs from an array "on the fly" (see the attachment), however the number of pulses generated depends on the array and the time delay in the while loop. I would have to manually add the pluses generated from each iteration to figure out the total number of pulses. Then I would have to reverse the process the figure out what the array should look lke in order to generate say n number of pulses totally. There must be a better way.

[Kevin_Price]

I'll try to take a look at your vi the next time I get to my LV machine.  Meanwhile I only have time to point you to an example I posted a while back that would attempt to perform on-the-fly frequency ramping while controlling the exact total # steps.  It's not an exact fit, but may serve as a head start to illustrate the idea of using the pulsetrain task as a Timing Source for a Timed Loop.

Your Timed Loop would need to be set to iterate every 400 Ticks of the pulsetrain output.  Left-hand-side Timed Loop properties can be accessed to find out if your loop is on time or late.  The entire scheme still cannot guarantee exactly 400 steps of each freq, but should at least inform you when you miss, and give you the opportunity to make appropriate corrections.

Here's a link directly to the post with the example.  I'd recommend reading back through the thread for some context on how that app differs from your own.

-Kevin P.

[lxx]

Thanks for your reply. I've looked at the thread you posted. It' is a great help to me. It seems like the "move one 1.vi" posted by pp42 is exactly suitable for my application since I only need to work under1kHz. It ramps up and down using given a finite number of steps. But I'm still not 100% understand how his code works and I want to write my own version. How did he control the number of steps that used in each segment? for example ramping up process, constant freq and ramping down part. Is this what the time loop does? confusing.

[Thaison_V]

Hi lxx,

I hope you're doing well.  You are right that pp42's VI may be a bit confusing since there is very little documentation on what he did in his VI, but hopefully I can take a stab at clarifying a couple of things.  The timed loop simply controls the rate at which the counter output frequency is being updated.  It has nothing to do with the actual number of steps taken over all.  It seems that he is using a combination of "the number of steps," and "ramp," controls in his algorithm (the section with all of the arithmetic and comparison functions) to determine this.  Again, the actual logic that is used to determine when to move up and down is all done in this part, and it is very difficult to decipher it without documentation.  Stepping through the code while it is running using Highlight Execution mode may be of help though.

Thaison V
Applications Engineer
National Instruments