how to generate an (re-) synchronized pulse train

[ToniSchilling]

Hello,

using a PCI-6601

I want to generate an endless pulse train of (e.g. 80Hz, high==low) synchronized to an external clock (ca.1Hz, ca 5ms pulse width).

The output should _re_synchronize with the clock if there is a clock signal but if one clock-pulse is missing it should continue hoping for the next.

It should look like this:

Perfect:
A1) tt________________tt________________tt_________...
A2) ooo___ooo___ooo___ooo___ooo___ooo___ooo___ooo__...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Output is too fast:
B1) tt_________________TT________________tt________...
B2) ooo___ooo___ooo___oxxx___xxx___xxx___xxx___xxx_...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Output is too slow:
C1) tt_______________PP________________tt__________...
C2) ooo___ooo___ooo__xxx___xxx___xxx___xxx___xxx___...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5_...
Clock is missing:
D1) tt________________._________________tt__________...
D2) ooo___ooo___ooo___xxx___xxx___xxx___xxx____xxx__...
    0__1__2__3__4__5__6__7__8__9__0__1__2__3__4__5__...

The external clock is assumed to be "the truth", so the pulse width for the 80Hz output is recomputed from time to time

by measuring the clock and then setting then output pulse width.

Until now I used register programming but this is not a must.

The examples I've found either generate finite pulse trains or the sync only once.

Is there a way to do what I want without software interaction?

Thanks in advance

Toni Schilling

[Jochen]

Toni,

there is no way to implement that in hardware on a PCI-6601. If the clock rate is slower than the output rate, you typically need to implement something like a PLL logic, but there is no such feature on the PCI-6601 to meet your requirements. 

The best way to do what you are looking for is using an R-Series board like the PCI-7811R, which provides an FPGA that can be programmed with LabVIEW FPGA. It depends on your requirements in terms of timing accuracy, if an alternative software solution is feasible or not. As long as you are not running your application on a real-time operating system, software interactions always add jitter,which might not be desireable, so a real-time or FPGA-based solution is probably preferable.

Kind regards,

Jochen Klier

National Instruments

[ToniSchilling]

Hello and thank you.

> "...there is no way to implement that in hardware on a PCI-6601..."

I was afraid to here this. 😞

But may be I explained not clear enough what we need.

1)

There's enough time for setup.

The plan was to measure the period of the external clock (ca.1Hz) and compute the High/Low time of the output signal by software.

If we do this continuously we can change the output frequency on the fly by setting the LoadA/B registers.

The external clock is stable enough so those changes are very small (compared to output frequency).

2)

What must be done by the _hardware_ is the _continuous_ synchronization of the output with the external clock.

2.a) The output should not stop if some external clock pulse is missing (or comes too soon)

2.b) The rising edge of the output should come together with the rising edge of the clock.

3)

There's no need to _start_ the output synchronized. It's OK if it's synchronized after a couple of cycles.

----

But now I have a new problem!

The friendly person at NI/Germany/techn.support told me:

    There's no way to get a HW-interrupt from PCI-6601 -- at least not via DAQmx programming.

    May be it can be done by register programming -- but for this I should ask the DeveloperZone.

I've found all these Interrupt-Enable, -Status and -Acknowledge registers.

I can't believe they are for nothing ... but I could not get it to work.

Can you help me or point to an example or so (I've not searched the Devel'Zone yet).

What I need is a "SW-callback" on every 80Hz output pulse that is generated and if possible also on each

pulse of the external clock.

----

Back to the pulse train problem.

May be this can be done by some register programming trick?

I've experimented with the ReloadCounterOnGate mode.

I think what I got was this (have to check this again):

A)

...___________________tt________________... (gate during high phase)

...__oooo____oooo____oxxxx____xxxx____xx... (OK, this is what I want)

B)

...___________________tt________________... (gate during low phase)

...____oooo____oooo___----XXXX----XXXX--... (output is synchronous but inverted)

...____oooo____oooo___xxxx____xxxx____xx... (what it should be)

Is there a trick, to say: ReloadOnGate but Toggle _only_ if output is LOW?

or: ReloadOnGate-and-allways switch output to HIGH?

or: Using a 2nd gate (sync to trigger) which closes on the 80th falling output edge

  and opens again on the expected next external clock.

..._tt________________________tt______________________tt_... (gate during high phase)

..._gggggggggggggggggggg____ggGGGGGGGGGGGGGGGGGGGG____GGGG..

..._oooo____oooo____oooo____ooXXXX____XXXX____XXXX____xxxx...

..._tt_____________________tt______________________tt_... (gate during low phase)

..._gggggggggggggggggggg___GGGGGGGGGGGGGGGGGGGG____GGGG..

..._oooo____oooo____oooo___XXXX____XXXX____XXXX____xxxx..

...____oooo____oooo___----XXXX----XXXX--... (output is synchronous but inverted)

Thank you,

Toni Schilling

[Kevin_Price]

I have a possible idea for you, but my experience is with LabVIEW so I can't offer any help with register programming, interrupt callbacks, etc.  Also, the continuous syncing will have to be a software function that continuously performs cycles of measure/adjust, measure/adjust, measure/adjust...   I know of no way to set up the hardware to do this autonomously.

The approach I would take is to add another counter task and a little extra wiring.  The other task will be for "Two Edge Separation", and you want to measure from the active (lead) edge of the master clock to the passive (trail) edge of your sync'ed pulse train.  There's a reason NOT to measure to the active (lead) edge of your pulse train and it's because counters can only measure finite times of at least 2 timebase cycles.  Whereas you would *like* to have an actual two-edge separation time of 0 between the lead edges.  That just seems like the kind of detail that's gonna burn you sooner or later.

Let's just suppose the master clock is nominally about 1 Hz and your pulse train is nominally 100 Hz and 50% duty cycle so I can talk through details with some specifics.  Whenever the two lead edges are truly sync'ed, you'll measure a 0.005 sec two edge separation time from the master clock to your pulse train's trail edge.  If you measure slightly *less* than that, your pulse train is going just a little too fast and needs its freq slightly reduced.  If you measure slightly more, then your pulse train is too slow and needs its freq slightly increased.

It is probably quite likely that you *cannot* expect to maintain perfect sync *without* constant monitoring and adjustment.  Fundamentally, you can only produce pulses with high and low times that are an integer multiple of the 6601's timebase of 20 MHz.  That card's oscillator won't be perfect, nor will it be utterly constant over temperature variations, etc.   So its idea of a perfect 100 Hz pulse train will in fact be very very close but not *actually* perfect.

And your ability to adjust the frequency away from a nominal 100 Hz will only be possible in discrete steps.

A 100 Hz pulse train takes 200000 cycles of the 20 MHz clock.  If you adjust your square wave to take 199998 or 200002 cycles, you can produce a nominal freq of 100.001 or 99.999 Hz.  Those are the smallest increments away from 100.00000000 that are possible with a 50% duty cycle. 

Statistically, it's very unlikely that the frequency needed to perfectly match the external master clock is even *possible* to produce exactly.  I think you need to *expect* an imperfect sync with continual subtle adjustments to your pulse train.  If you watched the signals on a scope while triggering from the master clock, I think you should expect to see your pulse train oscillating back and forth by some small amount, perhaps in the microsecond realm.

Summary (for 1 Hz master clock, 100 Hz user pulse train at 50% duty cycle):

1. Measure two-edge separation from lead edge of master clock to trail edge of user pulse train.  Use units of "Ticks" with 20 MHz timebase.  Nominal expected value when sync'ed is (1/2)*(20 MHz / current user freq) = 100000.
2. Subtract measured ticks from nominal to produce your "error signal". 
3. Use current error signal its recent history in a control algorithm to determine the amount of adjustment to make to your pulse train.  Hint: it will probably NOT be correct to directly change the user pulse width by an amount equal to the error signal.  I suspect that you'll want to pay closest scrutiny to the derivative of the error signal.  Note also that the correct AMOUNT of adjustment will depend on the RATE at which you run your measurement / adjust loop.
4. Change user pulse specs on-the-fly.
5. Return to step 1.

Caution: Let's suppose your software measurement / adjust loop runs at a nominal 10 Hz.  From the time you make an adjustment until the next time you do a measurement, your user pulse train will have generated almost 10 cycles with the recently-adjusted specs.  If you weren't careful to make your previous adjustment subtle enough, you'll find that you now have a *larger* error of the opposite sign, and you are well on your way to instability.

   You need to do an adjustment that lets you expect your *next* measurement to have an error close to 0.

-Kevin P.