Generate RC servo PWM signal from CNC controller motor PWM signal

[CambridgeMart]

I'm playing around with a CNC3018 Pro engraver and find the spindle motor supplied to be very limiting; I'm replacing the motor with a brushless motor with a much higher speed and torque rating and an RC model aircraft electronic speed controller. The PWM output from the CNC control board is 1kHz variable from ~10% to 100% and the ESC needs a standard RC servo signal PWM signal of 1.5ms to 2.5ms at 166Hz. I've tried a couple of approaches, firstly by low pass filtering the signal then driving a 555 in PWM configuation, but it's difficult to get the range of output pulse lengths I need, mainly due to trying to run opamps in the filter from a single +5V supply.
My next approach was to divide the PWM signal by six then use the resulting clock to gate the original PWM signal then stretch the pulses to a more useful length using an RC network and a Schmitt NAND gate. This circuit sort of works, but I can't get the pulses long enough reliably and the design is using 4 CMOS logic devices.
Anyone have a better idea than mine or done the same thing I'm trying to do?

[langwadt]

guessing it uses GRBL, so you can change that prescaler and max/min pwm and recompile to get what you want

https://github.com/gnea/grbl/

[LukeW]

RC filter the PWM signal, and generate a triangle wave, and feed both the triangle wave and variable DC level into a comparator? Should require 3 opamps and some passives.

[CambridgeMart]

LukeW - that's exactly what's sketched on the piece of paper on my desk right now!

[Ian.M]

If the CNC controller is to remain unmodified, it sounds like a job for a MCU with input capture to measure the input PWM pulse width and output compare to generate a jitter-free servo pulse, with the main loop running software mapping between the input and output pulse widths.   Any Microchip PIC with two CCP or ECCP modules could do it fairly easily, and I suspect that many ATmega AVRs could also handle it.

Another option - if there's open source firmware for the ESC you are planning to use, you could probably compile a version to accept the 1KHz PWM control signal directly.

However if you don't have the embedded development background and a suitable toolchain you are already familiar with, sticking to the analog OPAMP based approach may be preferable.  The analog solution is helped by the fact you don't need a great deal of accuracy - a few percent error in the spindle speed isn't an issue as long as it remains reasonably stable once set.

[David Hess]

There are a couple of tricks which will make the analog method more effective.

Instead of driving a 166Hz PWM generator directly from the averaged 1kHz output, average the output of the 166Hz PWM generator and compare it to the averaged 1kHz output inside the feedback loop of an operational amplifier which drives the 166Hz PWM generator.  Now accuracy of the 166Hz PWM generator is irrelevant and the operational amplifier can accurately control the relationship between the input and output with easy gain and offset adjustments.

Another thing I would probably do is phase lock the 166Hz PWM to the 1000Hz PWM to eliminate jitter although this may not matter.  The RC servo signal has considerable leeway in frequency so maybe just divide the 1000Hz reference by 8 to 125Hz although any integer division is practical if something closer is required.

[CambridgeMart]

Yes, it's GRBL; I'm now looking through the source code to find out where the PWM output is set up.

[langwadt]

Yes, it's GRBL; I'm now looking through the source code to find out where the PWM output is set up.

https://github.com/gnea/grbl/blob/master/grbl/cpu_map.h

you need to set the prescaler to get the ~166Hz, it is usually not very critical something like 50-300Hz should to work

Then set the max pwm and min pwm to match the 1.5/2.5ms

[Benta]

I wonder a bit about your specs.
The RC servo systems I know use a 20 ms (50 Hz) period with 1...2 ms pulses, 1.5 ms being neutral.
Is this a different system?

[Ian.M]

Although the classic Futaba servo signal is as you describe, modern high performance servos (and servo input ESCs) commonly accept a faster pulse repetition rate to reduce the response lag.

[TheSteve]

What processor does your ESC have, you might want to look into flashing it with BLHeli if it is supported which would then allow you to drive the ESC input with the regular PWM(assuming the correct logic levels). You can also convert the PWM to PPM with a "brushless converter". This was done in RC helicopters all the time 5-10 years ago when people wanted to install a brushless ESC but only had the regular PWM motor output to drive the ESC. The converters I used were based on an Atmel tiny13v processor.

[Benta]

Although the classic Futaba servo signal is as you describe, modern high performance servos (and servo input ESCs) commonly accept a faster pulse repetition rate to reduce the response lag.

Ah. Thank you for clarifying.

[CambridgeMart]

Cheers! After a couple of false starts due to the slightly confusing compilation process for GRBL, I've been able to get a frame length of 16ms with a pulse width of  between 1.6 and 2.6ms. I'm in the process of hooking up the ESC to ensure I'm able to initialise it with GRBL.
Regarding the 166ms frame length I mentioned, that comes from the old analogue RC systems that supported  6 or more channels; of course with digital RC gear, the pulse train is generated in the receiver so the frame rate can be higher and support many more channels.

[CambridgeMart]

For future reference, I found setting the prescaler to 128 to give a period of just over 2ms worked best, giving me the maximum resolution in pulse width. I can now use about 1/2 of the scale available within grbl or roughly 120 steps in the speed control ramp. I may benefit from rewriting the code in the ESC which is running a 32 bit ARM processor to be able to get a wider control range, but that's for another day.