Help me understand the capabilities of PLLs

Disclaimer - I'm a beginner at electronics.

I'm working on a project that requires either a rather large number of pulses from an encoder wheel, or I need to generate a lesser number of pulses and use a PLL to produce the desired number.

This is for a machine tool where the rotation of the first spindle must remain synchronized with the timing of a 2nd. In short, I've got a lathe and I want it to cut screw threads using a stepper motor.

My problems are solved if I can determine that a PLL can reliably generate a pulse train even when the input signal varies. Every distortion in the signal generated by the PLL will result in a positioning error on the stepper.

I don't know how to describe the load variation, but it's something like this:

Assume the spindle is turning at 60 RPM (1 RPS.) From this, I could be generating 128 PPR the thus generate a 128 Hz signal. My PLL would have to receive this and generate a signal 50x as great - 6.4 KHz. So we're guiding one piece of steel into another... when they meet, the spindle's RPMs will drop, at least for in instant, as the load increases. The drop is nearly instantaneous in a physical sense. It might be glacially slow in the electronic sense. I don't know. So the signal would drop from 128Hz to perhaps 100Hz in a fraction of a second. The PLL would have to respond without transmitting too many extra, or too few, pulses. Further, the frequency of the spindle pulses would be varying by a lesser degree all the time. Nothing is perfect. The PLL would have to respond in kind.

There are two cases. Since the PLL can't respond instantly, it can either 'sneak up' on the right frequency, or oscillate and settle on the right frequency. The first case is to be avoided - say the PLL's output frequency is too low - it generates too few pulses, adjusts, generates too few, etc. The end result is that we've dropped pulses to the stepper, and there's no mechanism to recover them. The stepper is 'behind' and will stay that way. The second case is better because if we generate too few pulses on one iteration, we'll generate too many on the next. On average, the stepper will be 'out' fewer pulses.

Also, I realize the 50x freq increase may be difficult to achieve in an acceptable way. I can reduce it with some effort (or expense) by producing more spindle pulses.

That's a lot of typing for not a lot of information. Can anyone here explain to me the capabilities of a PLL to keep this signal synced?

I have seen this very problem discussed elsewhere, quite recently, but I cant remember where.

The problem is that the PLL is following the speed of the headstock spindle and will only respond to speed changes after they have happened.
If the speed sensor on the headstock spindle is only generating 1 pulse/rev and the load increases, thus slowing the spindle, the PLL cannot know that the speed has changed until the next pulse from the speed sensor. The result will be a very drunken thread.

The best solution would be to use an encoder which generates a few thousand pulses per rev and divide these to drive the leadscrw stepper motor.
The problem is, such encoders can be very expensive.

You could always use gearing to speed up the drive from the headstock spindle to an encoder with fewer pulses/rev.

JimB

I've been asking around on a few different forums.

So ideally no PLL would be required - I'd drive the stepper directly from the encoder on the spindle.

Regarding 'following'... isn't this a problem for all such systems, whether a PLL or a microcontroller is used?

And regarding gearing the encoder up, on a auxiliary spindle... If I avoid the PLL, the RPMs required by a common encoder would be pretty dangerous.

The non-technical dilemma is that every penny spent on this project could be going into a replacement fund for the lathe. So it's gotta work, or I shouldn't do it... and it should be low-cost, or I shouldn't do it.

The motor itself will be rotating much faster. There may be a belt drive, but I guess that there will be fixed gearing from some high speed shaft to the spindle that is rotating at 60 rpm. If you can encode from a faster shaft you will have better resolution.

Diver300 said:

The motor itself will be rotating much faster. There may be a belt drive, but I guess that there will be fixed gearing from some high speed shaft to the spindle that is rotating at 60 rpm. If you can encode from a faster shaft you will have better resolution.

Click to expand...

Sadly there is no dependable shaft that's faster. The motor is connected to the spindle by 2 different belts and one of 4 pairs of pulleys of dubious accuracy. It's certainly looking like I'll be driving an auxiliary shaft from the spindle.

There seem to be a number of people working on this aspect of lathes, try googling "lathe electronic leadscrew" there are a number of projects written up on the web.

JimB

Yes, especially the ELS group, a Yahoo group built around one guy's excellent 'electronic leadscrew' project. He sells kits, etc, for a very reasonable price. The deal, however, is that I don't want to add a computer to the shop. What I'm building is far more limited and far simpler.

I had a bit of a break-through today which reduces the chance I'll need a PLL. Probably ;-)

My goal is to implement the electronic equivalent of a certain type of quick change gear box, a device that makes it easy to re-tool the lathe to cut different threads and with various feeds. I found that if I give a little on my requirements (don't support 5 threads with weird non-integer TPIs) then I reduce the spindle pulses by a factor of 4.