Frequency divided pulse output

[falkpl]

Not sure how to get exactly what I want.  I am using LV2010 and 6602 card

I need to put out 3 pulses for every trigger I see.  The triggers will come in at a slowly varying rate (between 1HZ and 150Hz typically), this should change but not too fast (+/- 1 hz change per sec max), I am measuring this frequency already on a seperate counter and pfi line

I need to put out 3 pulses evenly spaced for each 1 pulse in, to make it harder, I would like to also have a an initial delay (phase offset of some fraction on the frequency).

I was thinking of a retriggerable pluse train where I continiously update the frequency of the pulse or change the high, low times, is this allowed.  I do not need to be perfect but close should work (with in a few % of frequency).

Will this work, is there a better way given my current HW???

[TaylorG]

Hi Paul, 

Here's a link to an example on how to generate a pulse train with a variable frequency that could be useful to your application.  Hope this helps!

Generate a Continuous Digital Pulse Train With a Variable Frequency

[Kevin_Price]

With a 6602, of course there's another way.

First off, you're right that you can't change the pulse specs on the fly for any kind of finite pulse train, retriggerable or not. But if you roll your own finite pulse train, old-school style, then I think there *is* a way.

Suppose you had been planning to use Ctr0 to generate your finite retriggerable pulse train of 3 pulses. Ctr1 would have also been consumed as a helper to implement the finite pulse train. And then some other counter such as Ctr2 would measure the incoming frequency.

I would instead set up Ctr0 as a continuous pulse train which uses Ctr1 output as a Pause Trigger. Because Ctr0 is continuous, you can update its pulse specs on-the-fly. Then Ctr1 is configured as a retriggerable single pulse, with a high time calculated to allow exactly 3 Ctr0 pulses through.

I don't have ready access to data acq hw to test it all out, but here are 2 places I'd focus my troubleshooting:

- under what conditions can the retriggerable single pulse have its specs modified? I suspect you might only be able to change them no more often than every other input trigger. You'd need to query a very-deep-down DAQmx Channel property for counter output called "Read for New Value?" to determine when you are allowed to write new pulse specs. I do know that you can't write new ones until after the previously-written ones have been used to generate a pulse. I don't know offhand whether retriggering adds other complications. However, your app sounds pretty forgiving in that the incoming trigger rate isn't changing quickly.

- there always used to be a little quirk about retriggering on the 6602 and it's probably *still* true because I think it was hardware-based rather than DAQmx driver-based. The quirk was that the "initial delay time" sets the time from the 1st trigger to the pulse's 1st rising edge, but the "low time" determines that same interval for all subsequent triggers. If you are varying both the output freq and the phase relative to incoming triggers, be sure to update both the high and low times.

-Kevin P

P.S. I see that you work for Coleman Tech, who posted a "help wanted" ad recently. If you guys can make use of a certain someone with limited availability, feel free to get in contact...

[falkpl]

Thanks for the input.

Essentially I am imaging (strobe trigger) a three rotating blade system.  The shaft rotates at some speed 0-1200 rpm (0-200 HZ)- this is already comming in on a pfi line and measured.  I would like to send out 3 pulses for each trigger in, the trigger is offset in phase from the rotors by some fixed angle max is 60deg but most likely 0-20deg.  The RPM changes slowly only delta 10Hz/sec usually stable.  I was thinking retrig to lock the phase offset so I would always be synchronized is there a continious retriggerable mode (probably not) I could cascade 2 counters possible, one acting as a clock for the other one?  Make a continious varying pulse train synchronized to the RPM measured and then do a retriggered pulse train with 3 pulses out with a known low and high puled width- seems like a lot of resources on my 6602.

Are you looking for fulltime Labview development? can you relocate or just looking for contract work?

[Kevin_Price]

I *think* the stuff I described earlier is what I'd be trying, subject to the particular areas of troubleshooting focus.

When you talk about locking the phase offset, the difficulty I see is that while the phase angle may be constant,

the delay time will need to vary with changing speed.   That was where that whole business about querying

the "Ready for New Value?" property came in.  In general, any pulse specs you write must have been used

to generate a pulse before you'll be allowed to write new pulse specs.  The understanding I came to in the past

for a continuous pulse train was that you can only effectively change the specs every 2nd cycle.  While the

pulse is being generated from your old specs, you can't write new ones.  Once that pulse is done and you're

allowed to write new ones, the counter has already begun generating a 2nd cycle with the old specs.  Your

new specs go into effect for the 3rd cycle.

I don't know that I ever investigated the behavior of this stuff for a retriggerable single pulse.  I'd be hopeful that

it would work very similarly.  It's conceivable that you might be able to sneak in new pulse specs between the

end of the 1st cycle of old specs and the 2nd trigger, and perhaps they'd take effect for that 2nd cycle.

Bear in mind that this retriggerable single pulse is being used as a pause trigger for a 2nd counter that

generates a continuous pulse train (and is eligible to have freq updated on the fly, if needed).  The duration

of the 1st counter's pulse needs to be 3 periods of the 2nd counter's pulses so you can get the sync'ed

3-pulse output you'll need.

-Kevin P

[John_P1]

Kevin's suggestion reminds me of something similar I put together a while ago.

For more information about the initial delay vs. low time quirk, you can refer to this KB.

It sounds like you're on the right track--I'd probably be trying the same thing if I had to make this work with a 6602 or other DAQ card.  If the 6602 ends up not working out the way you want it to, you might instead consider looking into an FPGA-based solution.

Best Regards,