LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB 6215 - 10 Hz triggering with 2 TTL signals.

Hi all,

 

I use a USB 6215.
With two TTL output signals, two different colored lasers in an external device are to be triggered.
TTL 1 activates a blue laser. TTL 2 activates a green laser. 
This external device also outputs 2 analog signals that I can capture with the USB 6215.
While the lasers are active, the analog signals output characteristic values.

 

The two TTL signals should be output by the USB6215 as follows:
Both TTLs should be active for 10 ms every 100 ms, one after the other with a 2 ms delay.
So TTL1 active for 10 ms, then 2 ms delay then TTL 2 active for 10 ms.

The times should be adhered to as precisely as possible.
The two analog signals should be calculated during the time in which both TTL are active (i.e. over the 22ms).
The analog signals are sampled at 1 kHz.
The analog data acquisition via DAQmx is clear. 
I only have problems programming the timing of the digital triggers (TTL) accordingly.
Does anyone have any idea how to start? 
Maybe someone has already programmed something similar?

Thanks in advance
Pete

0 Kudos
Message 1 of 17
(321 Views)

I think I'd do this with digital outputs, not counter outputs. The 6215 only has 2 general purpose counters onboard and you kind of need three timed signals here (two square wave/duty cycle outputs and one timer to offset the two).

 

All of your timing is specified in ms, which is convenient since your analog is sampled at 1 kHz.

 

You can create two digital waveforms at 1 kHz- the first has T for the first 10 samples, then F for the next 90. The second has F for the first 2 samples, then T for 10, then F for another 88. Output this waveform as a digital output task and you should be good to go.

 

The 62xx series doesn't have dedicated DI/DO counters, so you will need to use another counter for your sample rate. You could set up a 1 kHz pulse train on a counter.... but your AI clock is already 1 kHz, and it needs to sync up, so just use that one! Read up on synchronizing multiple tasks. You'll want to route AISampleclock to be the source clock for your DO task. Then start the DO task, then start the AI task, and read the buffer every 100 samples (thus you read the buffer at 10 Hz, which is a solidly attainable rate). If you just want one shot, then you can just write this task once, but if you set up the DO as Regenerating and both tasks as Continuous then you can just read 100 samples from the buffer repeatedly for as long as you'd like.

 

Look up "task synchronization" in the NI Example Finder and you should find some good example code to get you started. Note that some of that will include start triggers; for this application you don't need a start trigger since the clocks are shared. You can ignore all of that stuff and it'll work out fine.

Message 2 of 17
(299 Views)

Your pulse timing needs have quite a bit in common with this other recent thread.  The main difference is that your earlier pulse should be set up with DAQmx Timing to use Implicit timing and to run with Continuous Sampling.  And your later pulse should be configured to be retriggerable using a DAQmx Trigger property node.

 

Your analog acquisition will require some care too bc your M-series device doesn't support retriggering an AI task in hardware.  You'll need to rearm it with software calls, which have overhead, and you have no more than 78 msec to do it.

    I see that task as a finite acquisition triggered by the earlier pulse and having a 22 msec capture time.  To reduce the overhead in your Read, Stop and re-Start sequence, it'll help to call DAQmx Control task to "commit" the task before the first time you start it.  I would *not* call the "DAQmx Wait Until Done" function in your main loop because it seems to seriously throttle max loop speeds

 

However I'm also remembering an issue I ran across where a USB-connected cDAQ system had about 80 msec overhead for these stop / re-start cycles compared to single digits of msec for a desktop DAQ device.  I can't seem to find the original thread, only another one where I referred back to it before.   So the caution is that what you're trying to accomplish *might* not even be feasible with the USB-DAQ device you have.   I'd start checking into this possible speed limitation first.

   On the other hand, perhaps you can live with excellent timing precision on the triggers you're armed in time for, but maybe missing about half of them?   Something like this would be fine for some apps, no good at all for others.  Dunno which kind you have.

 

 

-Kevin P

0 Kudos
Message 3 of 17
(298 Views)

I think he can use a continuous AI task and remove the data from the time he doesn't care about later on. That may be simpler than retriggering, but there are certainly several ways to skin this cat.

 

That said, I realized I may be confused on your timing. You said "both should be active for 10 ms, one after the other with a 2ms delay". I assumed you meant that TTL1 starts at t=0, and TTL2 starts at t=0.002. If you meant that TTL1 starts at t=0 and ends at t=0.01, then TTL2 starts at t=0.012 and ends at t=0.022, then the table will be different from what I originally said. It'd then be:

 

TTTTTTTTTTFFFFFFFFFFFFFFF...

FFFFFFFFFFFFTTTTTTTTTTFFF...

 

Your AI data will return with 100 samples but you can use Array Subset to just get the first 22 samples.

Message 4 of 17
(292 Views)

Yeah, what BertMcMahan said.   A simple continuous AI task where you toss out the data from the times you don't care about will *definitely* be a better approach.  Just use the earlier pulse signal as a one-time Start Trigger for the AI task.  This aligns your buffer of data so you can know which samples to retain and which to toss.

 

If you're not particularly familiar with counters, you'll probably prefer using his DO approach as well.  A DO task will be much more similar to AI & AO than a pair of counter tasks would be.  Counters are kinda my niche, so I tend to gravitate toward them reflexively, but there can be some learning curve when you're getting started.

 

 

-Kevin P

Message 5 of 17
(285 Views)

@Kevin_Price wrote:

Yeah, what BertMcMahan said.   A simple continuous AI task where you toss out the data from the times you don't care about will *definitely* be a better approach.  Just use the earlier pulse signal as a one-time Start Trigger for the AI task.  This aligns your buffer of data so you can know which samples to retain and which to toss.

 

If you're not particularly familiar with counters, you'll probably prefer using his DO approach as well.  A DO task will be much more similar to AI & AO than a pair of counter tasks would be.  Counters are kinda my niche, so I tend to gravitate toward them reflexively, but there can be some learning curve when you're getting started.

 

 

-Kevin P


Kevin, glad you brought this up- I thought about using two counter output tasks (using one as your AI Start trigger), but given his need for precise timing I thought he'd need a third counter to delay the start between the two. Since the 6215 only has two general purpose counters, I dismissed that idea...

 

But then I double checked and saw that you can actually specify an initial delay! I never knew you could do that.

 

OP, this is definitely a solid way to do things. You can set up two CO tasks, one with an initial delay. Use the earlier one as your Start trigger and you'll be all set.

 

Kevin: Would there be a chance the two tasks could theoretically drift out of sync over several hours/days of operation? I'd assume they derive their clocks from the same base, so probably not, but if anyone here knows, it's you lol.

0 Kudos
Message 6 of 17
(282 Views)

Yeah, i don't think the initial delay parameter has gotten enough emphasis in the docs and help over the years, and the shipping examples don't even wire up 'initial delay' at all.   This despite the fact that initial delay is used *IN PLACE OF* either high time or low time (depending on the pulse polarity) for the first pulse.  I'm pretty sure this true for any counter pulse task except buffered pulse output..

 

The default value for the 'initial delay' terminal is 0, which is tiny little lie, because internally all the pulse timing parameters *MUST* be at least 2 timebase cycles.  DAQmx silently coerces a 0 input value to the minimum legal value.  (It used to do this for high time and low time too.  I had some old code that counted on this, and got burned when a DAQmx upgrade made an important and long-stable test fixture start throwing errors instead of silently coercing the illegal 0 time value.)

 

If you don't wire up the initial delay value, the first pulse will happen with no perceptible delay when you call DAQmx Start because 2 timebase cycles will be a small fraction of a microsecond.  And that's probably what most people want most of the time.   But if your pulse task is triggered, you may want some delay from the trigger signal to the start of the pulse.  In *that* case, it's really quite important to know about and properly use the 'initial delay' value.

 

Just thinking about it now, I honestly am unsure how 'initial delay' is handled when the pulse is specified as freq and duty cycle.  My guess would be that it'd work similar to low time / high time.  Probably the initial delay value gets used directly for the first pulse (after any needed silent coercing that is).  And the active pulse time gets  calculated from the wired-up freq & duty cycle.  Actual duty cycle of the first pulse would generally not correspond to the wired in duty cycle value.

 

Well, that was a mouthful (and then some).  But wait, there's more!

 

Drifting out of sync will not be an issue when running on the same board.  All the I/O types would be deriving their timing from the same master timebase on the device.  A nice feature of the DO approach you brought up is that it trains folks to sync via shared sample clock, one of my main pet advocacy points around here.   Syncing via shared sample clock often eliminates the need for triggering *and* when syncing across independent DAQ devices, a shared sample clock prevents drift while a trigger won't.

    My counter approach would be subject to drift if extended across multiple devices, unless further unique work was done to share additional timing signals.

 

 

-Kevin P

Message 7 of 17
(271 Views)

Thanks Kevin. Incredibly enlightening, as always 🙂

0 Kudos
Message 8 of 17
(266 Views)

Hi Bert,

 

thanks a lot.

Yes you are right. 

TTL1 starts at t=0 and ends at t=0.01, then TTL2 starts at t=0.012 and ends at t=0.022.

Pete

0 Kudos
Message 9 of 17
(232 Views)

Thank you all for your detailed explanations. 🙂

 

Thank you all!
I will try it out and give you feedback.

 

Maybe as additional information:
The 1kHz AI signal (2 channels) can be sampled continuously (without trigger).

The two lasers should be triggered according to the pattern described. Every 100 ms, 10 ms TTL 1, 2 ms pause, 10 ms TTL 2.

The data should be extracted from the AI signal and calculated within the trigger time.

The calculated parts are then saved.

Pete

0 Kudos
Message 10 of 17
(230 Views)