The solution is to do each calculation individually ie calculate for 1/127, then 2/127, then 3/127.
If the aim is just to make the gear then there are 100 simpler ways.

If the fun is in making an electro-mechanical gizmo then go for it.

If you don't like electronics then go for an old school differential indexing device.

Even easier is to buy the indexer kit from "World of Ward". Processor comes ready programmed. Several posts elsewhere on this site about it. Photos of mine in my "Digital Dividing head" album.

As I recall in the earlier discussion (can't find it!), I started by arguing that the error was insignificant, but was soon persuaded it was worth correcting. (Accumulating error might become significant particularly if a coarse stepping motor drives a rotary table with a low ratio worm.)

Bressingham was suggested, but I settled for a simple averaging process that distributes the error around the circumference rather than letting it accumulate so that one tooth in a gear is malformed. The maths came from Duncan (many thanks!) and the code is:

nextSteps = ( (long)(divisionStepCount+1) * motorSteps + (long)rstatus.divisionSteps/2 ) / (long)rstatus.divisionSteps;

motorSteps is the number of micosteps needed to turn the rotary table through one revolution. It takes the table's worm ratio into account and the motor's base step (usually 200), and the motor controllers microstep setting.

rstatus.divisionSteps is the user request (ie the number of gear teeth wanted), and divisionStepcount is how far the turn has got so far.

nextSteps is the number of microsteps the motor will be sent to step the rotary table to the next position; thanks to the maths the number of microsteps jitters very slightly around the correct position on each division as necessary to share any error equally throughout the turn. No error, no correction applied. Bottom line: if there is an error it will be small, it is shared out to minimise the effect, and it does not accumulate.

Because stepper motors are themselves integer devices there's not much advantage in using floating point arithmetic which uses more memory and is relatively slow. However although all the numbers needed to control the motor are stored as 16 bit integers, Duncan's calculation is done at 32 bit precision to avoid overflow.

Dave

Not quite. You're on the right track except the motor and controller don't work in degrees. A typical stepper motor does 200 'natural' steps of per rotation or 1.8° per step. However the fiendishly clever motor controller can subdivide each natural step, at the extreme up to 250000 steps per revolution or about 0.0014° per step.

There's a trade off between speed and accuracy. It takes forever to spin a motor at 0.0014° per step. In practice I run my controller at 0.1125° per microstep (200×16), and that's fed into a 90:1 worm on the rotary table, giving 0.00125° per step at the job.

The software does the maths necessary to translate user needs in degrees or divisions at the table into microsteps at the motor controller.

Dave

The other way is to use a variation on the Bressingham Line Algorithm, treating one rotation and the number of holes as analogous to X and Y displacement along a line. Much easier and works by minimising the absolute error at each step

Neil

While microstepping improves torque ripple and position overshoot, it does not necessarily provide improved positional accuracy. This is particuarly true ff the load (torque) is variable. Performance depends on the motor, controller and load. It's easy to get caught up in the numbers but the whole system must be considered or you may be wasting effort for no real improvement.

Robert G8RPI.

In practice the problem has quite a low boundary. You are only ever going to cut gears up to 200 (plus whatever the JW large wheel skeleton uses) so the number of variables is quite small. For each of those 200 you need a maximum of 200 entries, average 100, in a table telling you how many steps to take. So the memory requirement is only 200×100 off 16bit numbers. You can do the calculations in excel and blow them into an eprom (except nobody does that anymore) have a few switches on the high address lines to select the tooth count and a couple of counters take the values and do the steps. No processors needed !

Precisely what I did with my ELS implementation and Electronic gear hobber – both sort of described in my various posts on MEW ( How I link to them is anyone's guess, or maybe Neil's…)

Bresenham takes care of it all with the smallest errors possible, and I used the Nucleo range of STM processor modules – Arduino lookalike/workalike, only MUCH faster , 140MHz, floating point, and US$15.00 for a board, with its programmer module..As Andrew said, whats not to like???

Mips/floating point, etc, are all VERY inexpensive today and while it's great to obfiscuricate software skills in retro-capability processors, why bother…

Bresenhams works very well in ALL these applications.

But, this is all intellectual masturbation if the OP just simply wants a system that he can apply and get to work, especially if he is not that able in the software space. In which case, I would suggest obtaining one of the mentioned systems that already work, and are more a diy assembly project than an adventure…

Joe

I made a 127 tooth gear using the calculate each position method as 360 x X/127 and a stepper motor with a close coupled harmonic gearbox. It required 88.8888 steps per degree, just under 252 steps per tooth. I decided that was going to be accurate enough for my needs.

Martin C

Bressenham is all very well for clever people who have blindingly fast processors which can do floating point arithmetic quickly. Mere mortals like me just start at zero steps, work out how many steps it should have taken from zero to the next position as an integer, subtract the actual number of steps to the present position (it keeps track), subtract one from the other and move by that number of steps. I think I might have included a dodge to make the integer arithmetic round to the nearest whole number rather than always down, but I can't remember, and it won't make a lot of difference.

For cutting a 127 tooth gear with a 40:1 worm driven by a 4800 steps motor (no I can't remember why I used 4800 perhaps it had belt drive in there) the series of steps is

1512, 1512, 1511, 1512,  1512, 1512, 1512, 1511……..

and so on. You will note that every now and again it does 1511 steps rather than 1512 to correct for cumulative error.

If anyone wants a spreadsheet detailing this send me a pm

Edited By duncan webster on 01/06/2019 15:13:27

Edited By duncan webster on 01/06/2019 15:14:17

Just to clarify, that picture is circles and lines drawn using integer Bressenham, the whole thing drawn and plotted ina fraction of a second.

To calculate holes on a PCD Y= number of steps in a circle, X=number of holes.

Starting at 0,0 then incrementing X by 1 and using integer Bressenham to calculate dY will give the optimum number of steps to the next hole that minimises the accumulated error.

Here's the pseudocode version off Wiklipedia:

plotLine(x0,y0, x1,y1)
  dx = x1 - x0
  dy = y1 - y0
  D = 2*dy - dx
  y = y0

  for x from x0 to x1
    plot(x,y)
    if D > 0
       y = y + 1
       D = D - 2*dx
    end if
    D = D + 2*dy

It uses only integers and no division so it can be implemented in integer BASIC, machine code, assembly language, C or anything else without the need of any special library or more than the most pedestrian of processors.

This case only plots in the octant where Y increases at the same rate or faster than X, which is what we want (always more steps than holes) so no extra logical tests or direction changes required.

Not that in our special case we want to make the holes at the transitions so we step the dividing head each time we increment the variable Y, and instead of having 'plot X,Y' we replace it with a 'drill hole' command.

Neil

P.S. Duncan's algorithm requires you to calculate how many steps to move to each hole. That is calculated as (number of hole to drill) * (number of steps) / (total number of holes).

This requires division which is much slower, and you need work out (number of hole to drill) * (number of steps)  then repeat the division every time to ensure the answer is correctly rounded (using integer artithmetic).

Edited By Neil Wyatt on 01/06/2019 16:44:41