Finite pulse-train generation with variable time lapses with NiDAQmx

[gritche]

Being a newby in Labview and NiDAQmx, I find it tedious to program the application I need to drive my experiment : I want to generate a finite pulse train, with variable delays between two consecutive pulses. These delays are known before the experiment starts, summurized in a table (element 0 decribes the time lapse between pulse 0 and 1, element 1 between pulse 1 and 2 ...). I would like to use NiDAQmx to program this. I had in mind the following scheme : two counters, first one counting time between pulses, the second one generating the pulse once "counter one" has finished his job. What I don't figure out is how to reprogram "counter one"'s register, without introducing unwanted delays in the time
sequence of my finite pulse train. I am using a 6052E DAQ, and I want to generate delays in a same pulse train ranging from 1 microsecond up to 20 seconds.

Thank you for ANY help 🙂

[Kevin_Price]

I'm afraid I'm a bearer of bad news. It sounds like you'd like to first capture a pulse timing pattern and then "play it back" with some type of buffered pulse train output function, right? That's a straightforward and reasonable expectation that I've also wanted for, oh, about 6 years now.

Unfortunately, NI doesn't provide any buffered output functions for their counters. You are able to change the delay and pulse times of a continuous pulse train on-the-fly in software (NI-DAQmx: Pulse Width Modulator), but you'll be subject to software timing limitations. You definitely won't be able to keep up
with pulse periods measured in microseconds.

The least expensive NI hardware solution is the 6533 family of high-speed digital boards, but I would recommend something else. With the 6533, to achieve timing precision down to 1 microsecond you'll need to define your digital pattern at every microsecond. So you'll have to work with a buffer containing 1 million digital patterns per second of output. Ouch!

A much more elegant solution, IMHO, is offered by one of NI's Alliance partners, Viewpoint Systems (PCI-DIO64). With it you only define the digital pattern at the times that there is a change in one of the bits, paired with the timestamp itself. You can get your 1 microsecond resolution on the high frequency pulses, but for the 20 second delay you keep 1 value in the buffer, not 20 million!

I have no affiliation with Viewpoint; I've merely used their earlier ISA board for pulse pattern generation and much
preferred it to NI's 6533. The drivers and software were solid and they gave good support when I had a couple questions.

-Kevin P.

[gritche]

Hello ! Bad news you are bringing me ... Just a precision : I don't want to capture dynamically a pattern, I just want to play it back. Can you tell me if the idea I had could work : I wanted to program a digital or analog waveform describing my pulse (the ulse's charachteristics are constant in term of duration and amplitude, i.e. 100 microsecond) and use the two counters of my board in the following manner :
Counter n°1 is loaded with the first time lapse between pulse n°1 and pulse n°2. Counter n°2 is loaded with the second time lapse between pulse n°2 and pulse n°3. I start the experiment : Counter n°1 counts down, when finished its output triggers the waveform generation AND counter n°2. While counter n°2 counts down, counter n°1's register is loaded
with the time lapse between pulse n°2 and pulse n°3. When finished, counter n°2 output triggers the waveform generation AND counter n° 1, etc ... Could it work ? How could I implement such a loop ?

I thank you very much for your help !

Gritche

[Kevin_Price]

I think I understand your overall app a little better now, but let me make sure. I'll describe below what I think you're after and you can correct me as needed.

You made references to triggering waveform generation with the counters' output pulses. I'm supposing that you mean analog output waveforms, right? I picture that you have some specific analog waveform that you need to generate repeatedly. The waveform itself is of fairly short duration, i.e., a "burst." You further need the intervals between burst starts to be variable. The need to generate specific delays between pulses is fundamentally aimed at providing the proper intervals between bursts.

Your basic concept is good, but I don't think it'll get you all the way. There are two key issues:

1. You depend on software timing to reprogram each counter while the other counter is doing its delay and pulse. For short delays, you may not get the counter reprogrammed in time. How short is too short? It depends on Windows, which can often starve you for several to tens of milliseconds, sometimes even more.

2. Retriggering an analog output isn't directly supported. There's a neat example to accomplish that capability anyway Retriggering Analog Output Waveform Generation (Note: uses traditional DAQ, but demonstrates concept) but it uses both your board's counters. Then you don't have them available to generate proper burst intervals.

Can you brute-force it by using a really big analog output buffer? The idea would be to define the burst waveform. Then for each delay interval, create an output array whose values are some neutral value (perhaps 0.0 V DC) and whose size corresponds to the delay time. Loop through all your pre-defined delays, appending the (variable) delay and (constant) burst together into one really big buffer.
Even with a 100 kHz output rate (10 microsecond resolution), you'd only need 12 Mbytes to define a minute of output.

The total time can be extended almost indefinitely if you write to the analog output buffer on-the-fly. The approach would be first, outside the loop, initialize your burst waveform array and a single array of neutral voltages corresponding to the very longest interval. Then inside the loop, you extract the appropriate subset of the delay array and feed it to the analog output buffer, then feed the burst array to the analog output buffer.
Set up the analog output buffer to be several seconds long, then feed it with about a second's worth of data about once a second. Note that there's a little bookkeeping to do to make sure you keep feeding the analog output buffer at about the right rate.

-Kevin P.

[gritche]

Dear Kevin,
Reading your answer brought me some kind of hope ! You had my experiment correctly descibed, though I was not using the proper concepts. Basically I am a biologist, studing photosynthesis. Each burst is used to trigger a lightning device. The photons emitted are used to probe my biological sample after an initial excitation. The initial reactions I want do monitor are quick ones (half-life time about 10 microseconds). The following ones have increasing half-life time, up to tens of seconds. Thus the great range of delays between individual bursts. I felt somehow pride of myself because I had also this idea of programming an array discribing the entire pulse train. I even managed to produce a short custom pulse train on the an
alog output. But I thought this would use too much memory for the real experiment, that I wanted to figure out a different methode. In fact, I didn't really new what an output buffer was, and your mail put is clear for me. Your idea sounds great AND feasible. Do you have any example of analog output buffer programming ?

Thank you !

gritche

[Kevin_Price]

I don't have any particular examples of analog output buffer programming that'd I'd recommend over the ones from NI, either from the LabVIEW help menu or here on the website. However, I'm no longer so sure that an analog output is the right way to go. I'm still not completely clear on your timing & signal requirements.

Three (sets of) questions:
1. Do you have any "true" analog output needs? Or are you just using the analog output as a means to produce a discrete signal of either 0 or 5 volts?

2. How does your lightning (lighting?) device work? Does it expect to receive a digital TTL-like input? If so, is it edge-sensitive or level-sensitive? That is, will it produce one fixed light emission for each input edge or will it produce light throughout the duration of time that the input is at the "on" level?
Or is it analog-driven, i.e., the output intensity is a function of the input voltage?

3. What timing details are critical in your experiment? How important is timing precision from one flash to the next? How important is timing precision from one flash to your "probing" of a reaction (via some analog input, I'm assuming)? Do you also need to control/track the cumulative amount of "on" time or # of flashes? Is it bad to flash without probing or probe without flashing? Can you probe continuously and flash sporadically, provided you know exactly when the flashes occur? Are the long half-life reactions timed relative to the same start as the short half-life reactions?
How do you measure your reactions' progress? Digital imaging? Analog signal? Pulse detector? Are you using LabVIEW to collect your experimatal data?

Depending on the exact needs of your experiment, you might be able to get there with the 6052E board. However, most of the solutions will probably be tricky to implement, especially if you're fairly new to LabVIEW.

If you have $ budgeted for hardware, I'd again recommend the PCI-DIO64 board & software from www.viewpointusa.com It's really nifty for generating precision-timed digital transitions at widely varying intervals. I'd also recommend you talk to your local NI rep, who may have some good pointers.

On the other hand, perhaps you have more time to spend than money. You should probably figure on several weeks to get things mostly ironed out and debugged. The first week or so may produce a program that does almost what you need, and it works most of the time. A couple more weeks and you'll have not-quite-what-you-wanted-but-you-can-live-with it, and it'll almost always work. Then there'll be an indefinite # of weeks of feature-creep and stomping out bugs that couldn't possibly have been caused by that simple change!

Meanwhile, post back some more details, and I'll see what help I can be.

[gritche]

Hello !
Well, I will try to be more precise while answering your questions. But first let me thank you very much for your help : your comments, questions and remarks are very helpful to help me shape my project, as you shed light on particular problems I strictly had no idea before !
1) I can certainly get on well with digital output as my flash device is triggered by TTL signals.
2) The lighting device is home-made, and I think it will be better for my needs to produce light throughout the duration of the input at the “on” level. In any case it will be driven by TTL-like signals. The intensity is manually set, so no analog control is required.
3) I will use Labview to collect the experimental data. The signal will be sampled during the light pulse : the rising edge of the TTL-like output signal will trigger both the lighting device and the data acquisition, the latter being stopped on the falling edge. The light emitted by the lighting device is called a “probe” for the following reasons : the photons are absorbed by the photosynthetic sample and “immediately” re-emitted at a longer wavelength. A photodiode acts as a signal transducer, and I monitor the intensity of this fluorescence. Knowing precisely when light pulses occurred after the initial start excitation (which is also a brief pulse of light but of a much greater intensity than the “probe” light) and the intensity of light emitted during theses pulses, I can reconstruct the kinetic of fluorescence decay. This kinetic reflects the behaviour of my biological sample. Thus no continuous acquisition is required as between two light pulses there is nothing to monitor. And all the half-time reaction are timed relative to the same “start” excitation as they reflect a jump sequence of an electron extracted by the “start” excitation : first jumps are quick ones (half-time in the 10 �s range) and last jumps are slow ones (half-time in the 1 s range). With respect to these kinetics, I would like a 1 �s precision. If not achievable, I could skip the quickest jump (but it would be a pity) and focus on the second one which has a 10 ms half-time reaction and a 100 �s precision would then be enough. But as we say in French : “Qui peut le plus, peut le moins !” (roughly meaning that when you can achieve the best, you easily can do the least). This precision relates to the position of one flash with respect to the others. I don’t need to be very precise on the duration of each individual light pulse : a typical value is 100 �s duration, but I can get on well with 90 �s or 110 �s, my data being an average of the light intensity emitted during the light pulse). All I want to know precisely is when it is fired.
4) Concerning the hardware, I already have a NI 6052E DAQ board, and unfortunately my laboratory cannot allow me to spend more money on this. I also have a fast acquisition board (IMTEC T3012) I intended to use to acquire my photodiode signal in place of the 6052E A/D converter. It has an old Labview driver, and I managed to upgrade it to suit my needs. It has an onboard segmented memory and can keep track precisely (it has a 60 MHz sample clock) of a trigger event. I am wondering if I can overcome the timing precision issue with this board, knowing that I strictly don’t care that flash n�1 is triggered at (t0 + 10 �s) or (t0 + 11 �s), provided that I know it, allowing me to place precisely my data point on the time scale. I can program the number of memory segments (i.e. the number of light pulses) and each one is filled with data coming from the photodiode upon receiving the rising edge triggering the light pulse. The precise date at which each triggered is received is stored in the board memory, allowing time reconstruction.
I do hope this is much clearer than my previous attempts ! Believe me, it is quite hard to leave biology for a while and enter the cryptic world of data acquisition !
Gritche

[Kevin_Price]

It sounds to me like you probably could use the 6052's counters to generate finite pulse trains with varying on/off times. You'll just end up with some dead time between pulse trains as your software detects that the prior one completed, and then reprograms and restarts the next one.
I'd expect you'd also want to reprogram your high-speed analog board during that same time, so that its sampling speed can slow down for the slower reactions.

Things might work roughly like this:
1. Load data describing pulse train (# pulses, pulse off and on times). Let's use default polarity where the pulse is high for "on." Perhaps the first pulse train will have ~50 microsecond on time (~5 half-lives of fast reaction) and 100 microsec off time, for 30 repetitions.
2. Set up high-speed analog board for appropriate sampling rate & # samples. Let's suppose the first capture is set for 1 MHz sampling rate, capturing 50*30 = 1500 total samples.
3. All your lighting stuff is triggered off the pulse's rising edge. The probe holds light on while the pulse is high.
4. Your high-speed analog acq. board is triggered off the pulse's rising edge, sampling at the rate you programmed. It's also set to be "gated" by the pulse so it only samples when the pulse is high.
5. You also setup your high-speed board to capture timestamps corresponding to rising (and falling?) edges of the pulse train.
6. After detecting that your first pulse train is done, reprogram the boards to look at the next reaction. Maybe it'll be a 5 msec on time with another 30 reps and you'll sample at 10 kHz. Meanwhile, there'll be a dead time of some 10's or 100's of msec to do this reprogramming, during which time there is no excitation or probing.
Hopefully, your timestamp marking can keep track of total cumulative time from the very first pulse if you need it, despite the variable reprogramming dwells.

There's one particular timing subtlety to watch for. Pulse widths are timed by the 6052 while the sampling is done by the IMTEC board. There's a chance that you'll get off-by-one errors due to timing differences. That is, you generate a pulse that is 50 microsec long according to the 6052's internal clock. That pulse "gates" the IMTEC's acquisition, which wants to sample once per microsec according to to its internal clock. If the internal clocks are off by a bit, you may occasionally get 49 or 51 samples instead of the desired 50.
If your IMTEC board can export its clock signals, there are ways to program the 6052's counters to derive their timing from those external signals. That would improve the timing synchronization.

-Kevin P.

[Dave_Le_Pelley]

Hi Kevin and Gritche,

I would like to do a similar type of thing where I generate a finite pule train of 17 pulses at 100kHz and then have a longer controlled gap (50ms?) and then repeat the same pulse train. I am using a PCI6034-E card with Trad Ni-DAQ so have no analog outputs. The easy way to do it is to run continuously the exampe VI "generate finite pulse train" which works, but the delay is then entirely software dependent. Any advice would be appreciated!

Thanks,

Dave

[WM_John_Weeks]

One way to achieve your goal is to set up the pulse generation in a continuous mode, and set up another counter in a continuous mode with pulse width set up (very carefull) to use as a pause trigger. So the second pulse generator would have an low period just the right length to give you 17 pulses from the first counter, then would go high (asserting the pause trigger) for 50 mS.

Oh- I just noticed that you said you are doing this with Traditional NI-DAQ. So change "pause trigger" to "gate". You will need GPCTR_Change_Parameter (if you are writing in C/C++) to set up the gating; I don't use Labview so I don't know the names of the vi's that do the equivalent thing, but I know they exist.