Finite Pulse Train TIO-Timing Specs

[jonny e]

Howdy everyone,

Got a question regarding the pulse specs of finite pulse generation with a 6602 (TIO chip).

I'm using a slightly modified version of the Finite Pulse Train (NI_TIO).vi found in the examples directory to produce finite pulses.

The slight modifications are to allow for some hardware triggering.  I am using counters 2 and 3 to produce a finite pulse train.

My external electronics provides the trigger to the gating counter.

I want all of my timing specs relative to this external pulse.

Let's say I want a delay of 10 seconds until my first output pulse is produced by the output counter; I want pulses to come every 1 sec; Pulses are 0.5 sec wide.

I know from looking into the VI's that the TOTAL delay--ie the time from my external trigger until the time the output counter outputs a 0.5 sec pulse--is equal to the "initial delay (in secs) in the finite pulse specs cluster in the VI plus the interpulse interval minus the pulse width.

Thus, If I enter a value of 10 seconds for initial delay, I actually expect the first pulse to be output at time = 10 +1 - 0.5 sec = 10.5 sec.  This is one-half second later than desired, but it is easy to correct.

Now for my real question: 

I'm usually looking at pulses coming about 20 msec after the trigger arrives.  The pulse interval is 5msec and the pulses are 0.5 msec wide.

 Even when I program my counters to get the timing I want with this correction, ie. implement the formula Desired Delay = "Initial Delay" - (pulse interval - pulse width), I still see my pulse arriving late by 1msec.  1 msec is enough that I care to get it right.  I don't understand the source of this delay.  Does anyone have any idea what could be happening?

It seems totally independent of any parameters I enter for pulse interval, intial delay, pulse width. 

Not sure if it matter, but I'm generating this finite pulse train inside of a much larger VI that is busy collecting and displaying data from a 6071E.

Any thoughts/help would be greatly appreciated!

[Kevin_Price]

Triggered finite pulse trains have what I consider a pretty odd quirk.  Based on prior threads, it's not exactly a bug in the code.  It apparently works "as designed," but I personally would consider it a bug in the design spec.  A number of people (including myself) have gotten surprised by the behavior and many have written to express the wish that it was different.  I don't immediately recall *any* who have applauded the implementation.

The quirk is that "initial delay" is applied only during the very 1st trigger and not on subsequent triggers.

Here's an NI article.  Here's a thread with a work-around example (the early part of the thread).

-Kevin P.

[jonny e]

Hi Kevin,

Thank you for getting back to me so quickly!

I agree that there could me a more friendly interface/way of programming triggered finite pulses!  Hopefully NI does it in the future.

For now I don't think, however, that I'm in the same boat as the people in the thread you referenced who are trying to do retriggerable pulse train generation.

I have a single trigger pulse, which triggers a train of, say, 5 pulses.

The real mystery to me is that I checked all the counter specs (number of edges for pulse spec 1 and pulse spec 2), and they are set as expected.

For instance, if I want an actual initial delay of 40 ms (with a 80MHz timebase) until the output counter actually produces the first pulse,

I see (with probe) the total number of edges that will be counted before output ( = "initial delay" edges + pulse spec 1 edges) =  1600000, as expected.

However the pulse arrives consistenly late by about 1msec ( = 40000 edges), and that's where I get lost as to why this might be happening.

Perhaps it is something in the way I have coded my vi....

Otherwise I'd expect the hardware to be plenty accuract with 80MHz timebase to make a transtion on a much faster time scale than 1msec.

For now, I'm just compensating by subtracting off 1msec from the desired delay until first pulse is output, and I don't feel an urgent need to give it a proper fix.

cheers

jon

[Kevin_Price]

Yeah, maybe you should go ahead and post the code.  Not sure if I'll have a chance to look at it immediately, but you should *not* have to live with a 1 msec timing error using hardware-based pulse timing.

Generating a *single* triggered finite pulsetrain should actually be much more straightforward than the posts I referenced for retriggerable operation.  Here's the timing sequence that occurs:

1. Start the counter -- I believe it will force the output into its idle state (low by default).

2. Trigger edge occurs

3. Output remains in idle state for exactly "initial delay."

4. Output transitions to pulse state (high by default)

5. Output remains in pulse state for configured pulse time (this would be like so-called "pulse spec 2" from traditional NI-DAQ)

6. Thereafter, the times will be based on your regular pulse specs, such as low time / high time.

-Kevin P.

[jonny e]

I'm using Traditional DAQ (not DAQmx), so I think points 3 and 4 are not strictly true for my VI.

(I'm am very hesitant at this moment to think about switching over to DAQmx :  I"m at the end of my graduate career and don't have the time to overhaul my program at the moment; and my VI works perfectly for my needs..except the 1msec delay.  I'll suggest future lab peoples move to mx...)

As I understand, for traditional DAQ:

1. Start the counter -- I believe it will force the output into its idle state (low by default).

2. Trigger edge occurs

3. Output remains in idle state for "initial delay."

4. Output transitions to armed state and remains low for "low time" which is computed/specified by the "frequency" and "duty cycle" specs.  So the total delay is the "initial delay" + "low time"

5. Ouput transitions to high state for a time, also determined/computed by the frequency and duty cycle specs.

6.Thereafter, the times will be based on your regular pulse specs, such as low time / high time.

OK, I didn't want to drag the VI into it, but it seems there is no other way; and I really want to know why my timing is not quite as I would expect.

The VI I posted has 3 outter sequence frames.  The action, as far as we're concerned in this post, is in outter frame number 3; inner frame number 3, case True, subVI Finite Pulse Train (NI-TIO)-jev4.vi.  This VI is "slightly" modified from the example that came packaged with LV "Finite Pulse Train (NI-TIO).vi"  The modifcations I made were 1. removed the while loop that checked the status of the counters, because I needed this subVI to return before the pulse train had actually finished executing.  2. Added start trig capability to the gating counter's gate.  (Maybe  this is the source of the 1msec error?).

There is a variable "stim delay (msec)"  that specifies when the first high pulse should be output from the 6602. (device 2  for me.)

To complicate things further, " stim delay" is actually relative to another variable in Neurochip-legacy.vi called "record delay."  Record delay specifies the delay between the the arrival of the trigger pulse and start of data acquisition on NI6071E.  (had to do this because of the way things are set up in the lab).  This trigger pulse  is shared with the 6602--it is hardwired in a breakout box to also be routed to my 6602 card.  Thus, if the trigger arrives at time = 0, record delay = 20 msec, and stim delay = 40 msec, I would like to see my first output pulse of the train (on the 6602) come at time = 60 msec.

For the time being I have set the "initial delay" = record delay + stim delay - (pulse interval - Ta), where pulse interval is just 1/"frequency" parameter for finite pulse generation, and Ta is the desired width of the output pulse which in turn specifies "duty cycle" parameter.  For the moment, I've also hardcoded in a 1msec correction--which was the whole reason for the original post.

Maybe in all this arithmetic and wiring I've made a goof somewhere...if so, maybe a fresh pair of eyes would help.

Ok, so if you are brave enough to check out the code,  it is attached.

If you find that you are getting the same result as me, I would love to know it.

If you are getting different result than me, I'd love to know it.

If you see where I went wrong, I'd really love to know where.

Thanks very much

jon

[Kevin_Price]

Ahhhhh -- traditional NI-DAQ.  I can't look at code now, but will try to talk through some very generic ideas.

1. The steps 1-6 and the formula you describe for calculating initial delay sounds right according to the NI article I linked before.  I don't have any personal experience (or at least none I remember) with using initial delay in tradtional NI-DAQ, so can't offer any war stories either.

2. Are you exactly 1 msec off?  Is it extremely consistent?  I'd think hard about the overall system to determine what kind of thing might conceivably lead to such an exact round error.  Is anything being calculated in msec?  Might there be a truncation down or rounding up to the wrong integer value?

3. Try some "scientific tweaking."  Change pulse parameters one at a time and observe if any of them change the 1 msec error.  Look harder at the triggering setup you mentioned too.

4. Try testing the code with the hardware 1000 times slower.  Everything that's now in msec scale moves into seconds.  (This may or may not be useful, depending on a lot of particulars in your setup.)

5. etc.  Just basically some systematic, strategic troubleshooting.  What inputs can you change?  What output reactions can you observe?

-Kevin P.

[Jesse_O]

Hello jon,

I have a 6602, and I have ran the Finite Pulse Train (NI-TIO) example program.  I am not clear on all the setting you are using in your application, however I believe you would like a 40ms total initial delay.  I have accomplished this, and the attached image shows the parameters I used.  I set the pulse output frequency to 10kHz, and the initial delay to 0.03995 seconds. 

This gives me exactly 40ms delay between my trigger and my output pulse.  I measured this by using another counter board (M Series) and performing a 2 edge separation measurement.  I measured the time between my trigger edge and the first pulse edge. 

I used these values because total delay before the first pulse = initial delay + (1-duty cycle)* (1/frequency).  With the settings I have used and when using the Finite Pulse Train (NI-TIO) example program can you get a 40ms total delay time?  Next, with the example program and your required settings can you get the 40ms delay?  If not, what settings are you using and how are you measuring the two edge separations?

Regards,

Jesse O.
Applications Engineering
National Instruments

[jonny e]

Hi guys,

Thanks very much for all your responses!

I tested the VI over wide range of every parameter and nothing changes--I still have the 1msec issue.

I am strongly suspicious that this is related to the actual triggering because my external electronics outputs a trigger pulse that has width 1 msec.

The trigger from my external electronics is active low: most of the time the trigger is sitting at +5 except for a special condition(well, it is not that special, it just synchs to powerline 60Hz), in which case it goes low (0 V) for 1msec, then returns back to hi.

So.....I am wondering if in my gerryrigged VI "Finite Pulse Train (NI-TIO)-jev4.vi" I have not properly set the gating counters gate to recognize a falling edge?  I used the set attribute vi, setting the "Start Trigger Polarity" attribute.  If this gate is not being set correctly to trigger the gating counter off a falling edge, maybe it is seeing the rising edge 1msec later than it should  be.  Hence the 1msec delay.  Any chance one of you fellas can tell me if I am setting the start trig polarity properly?  (The vi is contained in my earlier post.)

This seems to be the only plausible situation I can think of....

Sorry to cause all this trouble on account of being a technological neanderthal who still works in trad. NI-DAQ

cheers

jon

[jonny e]

ps. I should add that all of the parameters in the cluster (initial delay, frequency, etc.) for finite pulse gen. are being set exactly as I would expect.

[jonny e]

pps. I should also add 2 more tidbits:

- my data acquisition on 6071E is triggered properly off of a falling edge. The data acq. trigger is shared (hardwired in breakout box) with all other counters I am using (counters 0-3).

- triggering single delayed pulses using the VI that comes packaged with LV works exactly as expected in terms of delay time.  They are also triggered off the falling edge.

Finally, one might suggest why not rewire the trigger to be active high instead of messing around with software.  Could do this, but don't really want to mess with pulling apart electronics since my time frame is very short...thought fixing software (if it can be solved that way) would be the path of least resistance.