Synchronising AC signal generator frequency to motor RPM using encoder signal

[Ammad156]

I want to conduct an experiment where I need to apply an AC voltage having frequency synchronized to shaft rpm. The motor that drives the shaft has an encoder which I can use to measure the speed continuously and use as an input for the AC voltage frequency. I have a basic AC signal generator and tried to match it manually with the motor speed, but as the speed is never constant I observe small shifts in the speed and AC frequency and it never matches. I have NI-DAQ USB-61620 and I have already set it up to acquire the encoder Z index signal.

Any help or assistance to achieve this would be highly appreciated.

Thanks,

Ammad.

[Kevin_Price]

There isn't enough detail in the requirements to say for sure.  Here's one approach, along with its assumptions and implications:

The following will let you generate a repeating analog waveform whose frequency is sync'ed to your actual instantaneous motor speed.  Every speed variation will be reflected in your AO waveform though bear in mind that small variations may not matter for your purposes (whatever they are).

1. Define your AO waveform *spatially* relative to motor *position*.  If you want 1 cycle of your waveform per rev and you have an encoder that produces N cycles per rev, then define your full sine (or whatever shape) cycle with N samples.

2. AO should be set up to use encoder ch A or B as a sample clock for generating the AO waveform.  It should also be set for continuous acquisition.

3. No matter what the instantaneous speed is, each incremental position will generate the next AO sample -- i.e., the AO frequency will vary proportionally with motor speed.

4. Many variations are possible depending on how you define your buffer of AO samples.  For example, suppose you need your AO freq to be 5/24 of your motor's revs/second speed.  Well just make sure you use exactly 24*N samples to define exactly 5 AO cycles.

5. You may run into some problems if you have a low-res encoder or need an AO freq that's much higher than the motor's revs/sec speed.  For example, if you have N=1024 and want an AO frequency that's 1000x the motor's revs/sec, you can't do things this way.

6. There are functions in math and text languages like "rats()" for doing rational approximation which can help you figure out difficult ratios between AO frequency and encoder resolution N/rev.   There's also this pure LabVIEW solution from yours truly originating 20+ years ago.  (Follow through to thread end for useful updates.)

-Kevin P

[Ammad156]

Hello Kevin,

Thank you for your detailed and step by step guidance once again, as you helped me in my previous problem where I wanted to synchronize my voltage acquisition with motor rotational position.I have understood most of what you have explained and try setting up based on this. I could'nt quiet understand points 4 and 6. My shaft RPM is in the range of 150-170 RPM and I want to generate AC signal having 8-12 cycles per 1 rev, I think its not that high and can be generated based on the hardware that I have.

To give further detail I want to generate a square wave, frequency of which is synchronized to shaft speed, and I want to apply the AC signal back to the shaft. The shaft RPM would be in the range of 170, and I want the frequency of the AC frequency to be 8-12 cycles per shaft revoulution. The main aim of this is to always keep specific (8-12) segments of the shaft always at higher potential (+V) and the rest as lower potential (-V).

As in my previous set-up the shaft is connected to the motor (having an encoder) throguh belt-pulley drive having ratio between motor to shaft: 18/32.

The link to the previous problem that you helped me with:

https://forums.ni.com/t5/Multifunction-DAQ/AI-timing-signals-USB-61620/m-p/4363304#M105176

Thanks again gor your help,

Ammad.

[Kevin_Price]

Let me try to walk through the math from my point #4.

From your linked thread, it sounds like you have a 1024 cycle/rev encoder on your motor.

From this thread, it sounds like the shaft in question moves at a ratio of 18/32 = 9/16 compared to the motor & encoder.  So 16/9 of an encoder rev corresponds to 1 shaft rev.   Or (more helpfully) 16 encoder revs corresponds to 9 shaft revs.   This is what we'll work with.

So you want 8-12 cycles of your AC signal per *shaft* rev.   Let's work with 10 for now.  Thus 9 shaft revs * 10 AC cycles/rev = 90 AC cycles per 16 encoder revs.

How many samples?  Well you'll need 16 encoder revs * 1024 encoder pulses/rev = 16384 samples.  How many samples per AC cycle?  That's 16384/90 ~= 182.04

This doesn't fit *exactly*, but I'm guessing that you'll be able to do some rounding for the sake of your situation.  The 90 cycle pattern will repeat every 16384 samples.  Most of those cycles will contain 182 samples.  Since 90 * 182 = 16380, there'll be 4 AC cycles that need to contain 183 samples instead.  Space those ones evenly amidst the 90 total, and your +V/-V transitions will never be more than 1 sample = 9/16 * 360/1024 ~= 0.2 degrees off from nominal.   That's probably closer than the mechanical tolerances from your belt drive system.

The point of my comment #6 was that there are ways to do some extra math to get pretty-much-exact integer ratios to represent any fractional number.  Sometimes this is useful when the "real world" dictates that both numerator and denominator are driven by things that are inherently integers (pulley teeth, encoder cycles/rev, etc.).

    However, we already arrived at just such an integer relationship by showing that 90 AC cycles corresponds to 16 encoder revs (or 16384 encoder pulses).  It wouldn't be proper to go further and try to change the 16384 / 90 ~= 182.04 relationship into an exact integer b/c the 16384 and the 90 already represent the true ratio between encoder pulses and AC cycles.  That's the ratio you need to stick with to keep your AC signal in sync with your shaft rotation when the shaft is driven by a 18/32 pulley arrangement.

-Kevin P