I'm trying to use a usb-6351 daq card to generate two pulse trains (period of 20us) to trigger my pump and probe laser. I would like to use a square wave(in the frequency ~10Hz) to gate the pump. I would also like to tune the delay between the two pulse trains. So I tried to use finite sample generate and digital edge trigger for the pump and probe. Basically if it saw one rising edge of the trigger, the probe will generate (10^8(100MHz clock)/2000/10 = 5000) pulses and pump will generate half that number of pulses. This way i'm hoping it would generate a continuous probe light with a gated pump light. However, what I'm seeing is that both pump and probe are gated. The finite sample generation works well if I use 1 pulse and 2 pulses per trigger since I can read these easily on the oscilloscope. For more pulses generation, the oscilloscope we have doesn't work quite well so I directly trigger the laser and image the light. The pump seems gated but probe is not continuous.
Attachment is my block diagram.
Any ideas would be deeply appreciated!
P.S. By the way, I've tried pause trigger function too. I'm having trouble changing the delay that way. But the pause trigger cannot be used with start trigger together and pause trigger seems to accumulate some delay overtime.
Solved! Go to Solution.
Hi I'm poster and i'm attaching my program in case it helps.
Btw, I don't know why if I use pulse instead of toggle mode in the program, it will output pulses but with a non-zero DC signal, so I'm using toggle here.
I don't fully follow some of the details in your writeup, especially when comparing to the code you posted. You say both CO tasks appear to be "gated". But the code shows no sign of configuring a "pause trigger" to perform any gating action. (And as you also mentioned, a counter output task can't have both a start trigger and a pause trigger.)
You also talk about generating 1 or 2 pulses per trigger, but your code (and the default values of the front panel controls) configure the counter tasks for 5000.
All that being said, I think you might be pretty close. The way to get the pause-triggering *effect* is to use a 3rd CO task to generate a clock you can use as a timebase for your pump task. If you create it on Ctr2, you'd specify "Source of Ticks" for the pump task as something like "/Dev3/Ctr2InternalOutput". You can then "gate" this Ctr2 output task by configuring it to use the 10 Hz square wave as a pause trigger. As this gets paused, so will your pump task.
You'd want to calculate your Ticks differently for your pump and laser tasks since they'll be using different frequency timebases while you want the same output freq.
You should also be sure to start all 3 Ctr tasks and the 10 Hz gating signal before the Start Trigger gets asserted.
I know of no reason why pulse mode vs. toggle mode would have any effect on the output voltage.
Thank you for your timely and detailed reply!
Sorry about the confusion in my write up. I'm using the finite sample generation to get an effective gating. Because the probe will generate 5000 pulses to fill the entire 0.1s but pump will only generate 2500 pulses and will fill only 0.05s. I think this can give me a gated pump and continuous probe when triggered by the rising edge of the 10Hz square wave.
The part I mentioned pause trigger is that I've tried directly using pause trigger property node with an external square wave to gate a continuous pulse train. But this seems to accumulate time delay in the pump, so I gave up that way and used this way instead.
Your suggestion seems like a good way of realizing Pause trigger effect. I will definitely try it! You mentioned "You'd want to calculate your Ticks differently for your pump and laser tasks since they'll be using different frequency timebases while you want the same output freq." Do you mean "pump task" here the pump pulse train and "laser task" here the probe pulse train? As I understand, the ticks will be gate, so it will work if I use a continuous generation of pulse train (with say pulse generation of 2000 ticks) for pump and 2000 ticks for probe?
Meanwhile with the clarification, do you have any suggestion why the old method is not working?
Again, really appreciate your help!!
I *think* I'm getting a better understanding now. Here's what I believe you *actually* want to do:
1. Generate 2 distinct 50 kHz pulse trains, one for a laser probe, the other for a pump.
2. Their rising edges should be offset from one another by an amount you control via the "initial delay" property.
3. An external 10 Hz square wave should be used to enable/disable the pump pulse train. Over the course of every 100 msec, 50 kHz pulses are generated for 50 msec, no pulses are generated for the other 50.
4. There's no other particular reason to limit the # of total pulses or to have to keep re-triggering. Those were both attempts at different approaches when other stuff didn't seem to work right.
If all those things are correct, here are the things to modify in the code you posted.
5. Set "Source of Ticks" for *both* your existing tasks to be "/Dev3/Ctr2InternalOutput".
6. Set *both* existing tasks for Continuous Samples
7. Remove the Start Trigger config and retriggerable setting from *both* your existing tasks.
8. Add Pause Trigger config to *only* the pump pulse train task, using the 10 Hz signal as the pause trigger signal.
9 Configure a 3rd counter output task for "Dev3/Ctr2" (matching up with #5 above). After a closer look at your original pulse specs (short pulse, long idle time), I'd configure this for either 10 or 20 MHz to support a similarly short pulse capability.
10. Use a sequencing method (I usually rely on dataflow using the error cluster) to make sure you start both your original CO tasks *BEFORE* starting the 3rd counter task.
And that should be all.
Thanks for your patience and detailed solution!
You're right about the purpose of the program.
I have several questions about your solution:
1. Why is there a third counter output task for counter2? Can I just use the 100MHz internal clock as in the program?
2. As I mentioned, I have tried to set up the program of a continuous pump pulse train pause triggered by the square wave and then use pump to trigger start the continuous probe train. What I have noticed is that, the delay between pump and probe will change overtime on the order of us/min. I was thinking the pause trigger will somehow take some time to process and add some time delay. Do you think it's possible and your solution will also have the same problem or is there a better way to synchronize the two pulse trians?
Thank you very much!
Thanks for the suggestion!
I tried again the pause trigger node. It turns out if I use an external squarewave generated by function generator, there will be a delay change problem. But if I use the digital wave generated by the daq card (output it to port 0 and use BNC cable to connect it to PFI3) to pause trigger the pump, the delay will be fixed!
However, if I put it into an oscilloscope or feed it into pulse generator to drive the laser, I can see that the probe is not continuous.
Attachment is the program I tried. By the way, I try to add the error to control data flow. The thing is the generation of squarewave will not transmit error until the generation is done. I would have to break the subvi to make it flow properly. I will work on that later.
I've got just a couple minutes.
My purpose for the 3rd CO task to act as "Source of Ticks" for both other tasks was to sync the start of those other pulse trains. Your use of on output to trigger the other task comes close, and maybe that's good enough for your usage. I kinda suspect not though, given your concern about delay changes on the order of microsec / minute.
I suspect the "delay change" is a result of the pulse timing being derived from your DAQ device's timebase while the external 10 Hz pause-triggering signal comes from some independent timing source. Whenever there are 2 distinct sources of timing, they'll almost always drift relative to one another. Timing accuracy for many of NI's DAQ devices is something like 50 parts per million. Other timing sources might be better or worse, but no matter what, the two will *differ*.
And now finally I think I have a little better understanding why your original approach tried to retrigger finite pulse trains. I can't look at code now to review, but that kind of approach can keep re-syncing to the external 10 Hz signal often enough that the "clock drift" phenomenon woiuldn't be very noticeable.
Can you describe the "big picture" of this app a little more? Why does this clock drift / delay change matter for your test setup? How long must you run? And other details too. I suspect some compromises will need to be made, so it's important to have a better sense of which things are truly *requirements* and which things are more like *preferences*.
Thanks for your detailed explanation!
Sorry I didn't make it very clear in my last post. They delay problem can be fixed with the internal generation of the 10Hz squarewave, which is good enough for us. We can just use the internal generation for our purpose. So in my mind, either of the two ways would work ideally.
The purpose is to study us-range optical pump probe(pump and probe delay around 1us, 10s, 100s us), the resolution should be within "us" range. And for each point, to get good signal to noise ratio, we need to integrate at least 5min and possibly longer if the signal is small.
Since it's ok for you to generate the 10 Hz square wave on the same DAQ device instead of using an external signal, that'll make everything MUCH simpler.
Your main 2 CO pulse trains (pump and laser probe) can be Continuous Sampling tasks. Make a 3rd counter the "Source of Ticks" for both of them. Run that 3rd counter at 10 MHz and start it *LAST*. Set your 4th counter to run at 10 Hz and use it as a Pause Trigger for your pump pulse train task. I'd say you may as well use the 3rd counter as the "Source of Ticks" for the 4th counter to make the phasing of the pause trigger repeatable. But again, the 1st, 2nd, and 4th counters should all have been started before you start the 10 MHz 3rd counter.
No "Start Trigger" is needed this way, which is important because a Start Trigger wouldn't be allowed for the pump pulse train task that already uses a Pause Trigger.