Arduino Gear Hobber

I think it would be good to start a new thread on this to see if any arduino buffs out there will be willing to try controlling a gear hobber with Arduino specifically. As I see it the most critical part of the problem is that no steps are missed in synchronising the cutter spindle to the gear blank rotation. It also must keep in sync when it is stopped to measure the progress of the cut.

Missing steps would produce scrap if they happened near the end of the process, just as happens in CNC. The two options for avoiding this are over specifying the motors and having closed loop drivers for the motors. If you are going to the expense of designing and building something like this I don't think penny pinching on the motor and driver setup is a good idea.

Martin C

Can we start by guestimating the size of motor needed, which depends on the size of the gear and hob, plus the material. Assuming mild steel, how big are the gears being cut, and how much metal does a hob need to remove per turn?

Also, can anyone explain how a gear hobber works in terms of moving the blank past the hob's teeth? Watching this video is helpful. Looks to me as if the hob and gear are rotated at a fixed ratio, and the gear and hob height, angle and feed are all adjusted manually by positioning a compound slide. The machine is shown working, but it could be feeding manually or automatically. I reckon the hobber in the video is manual, the set-up being:

1. Set the required ratio between gear blank and hob
2. Set the hob to height.
3. Start the machine
4. Move the hob into the blank by turning a handwheel until the hob starts cutting. Allow it to do a turn or two around the blank, increase the cut depth by hand, repeat until the gear is finished.

Design decision: is the Rutzen Dreadnought Gear Hobber to be fully automatic (needing 3 motors), or can the computer just get on with turning the hob and blank together while the operator controls cutting depth?

I like the operator controlling depth manually because he can hear when the cut struggles and just back off a little. Provided the steppers aren't overloaded by taking a deep cut, they shouldn't miss steps, fingers crossed! I don't think it's too difficult to program 3 steppers for full automatic if wanted, but might be harder to set feed rates correctly to avoid overworking the steppers,

Dave

The hob works like a worm running in a worm wheel except the worm has teeth on it and traverses across the blank cutting as it moves. The feed can be by hand so no stepper drive there. You only need one stepper motor when using a vertical mill, the main spindle is powered by whatever. You do need to sense the position on the cutter at all times and its position must be accurate, 4000 P/R is what is suggested so you need a rotary encoder geared up to provide this. It can be driven by a toothed belt from the main spindle or by gears but there is no load on this. The power needs to drive the blank will depend on the method used. If it is worm driven then the power needs must drive the blank with no missed steps. A 4 amp stepper motor will do this . it isn't having to push against the cutter, the helix angle of the cutter keeps the blank rotating. The blank is set at the helix angle of the hob.

OK, so how do you see your physical build? Is it a dedicated machine like the one in the video, or a milling machine attachment? If an attachment, I imagine the mill spindle turning the hob with a rotary encoder measuring the hob's rpm. Given hob rpm, hob position, and the desired ratio, the computer could turn a gear blank in sync via a stepper motor. One stepper motor, one driver, and a rotary encoder. Also, a power supply and control box with start/stop button and whatever is needed to set the wanted ratio. Maybe a display showing the ratio and rpm. Fairly simple?

What ratios are required?

Dave

Edited By SillyOldDuffer on 27/07/2020 21:39:45

It's a non-trivial problem to sync one sampled system with another at a different rate and maintain short term synchronism. There's also the added complexity of maintaining the sync as the spindle accelerates and deccelerates. It's essentially what a CNC mill does when it rigid taps. You don't need to be in the wrong position by very much to jam/break the tap.

The problem is basically one of signal processing and realtime software and is the key to making a CNC hobber. In comparison the issue of driving force and missed steps is fairly simple.

Andrew

Err...

Toby Kinsey's GearHobber which is being serialised in MEW at the moment uses an Arduino Nano ... and works.

Neil

(His solution was to use steppers to drive both spindle and cutter)

Edited By Neil Wyatt on 28/07/2020 01:47:30

How to make the photos show smaller on a page? Do I resize them externally and upload again?

Takes up a lots of vertical place when I just wish to chip in and add my bit...

Somewhere on the forum is my post on rotary table controller I did. Apart from the usual rotary table functions, a hobbing function was also added ( its only software right?.)

Another fellow member in the UK also built up one of these as a hobber only.

On stepper sizing, one issue as mentioned by John is the stepper acceleration/deceleration during start/stop. When hobbing, the blank peripheral speed is tied to the cutter pitch and it's rpm. So the worst condition for acceleration is with a large pitch, small diameter gear. The blank has to get to 'pitch' peripheral speed, matching the rate of acceleration of the hobbing cutter. This is where the stepper would lose steps if so prone. An undersized stepper, poor selection of driver voltage, excess friction or mechanical inertia in the blank drive train, etc, all contributors to lost steps. Mechanical resonances don't help either.. I did experience some issues and fitted rattle damper to the stepper shaft and that resolved all..

The subject heading is for an Arduino application - my setup is not really applicable - I used an STM Nucleo, an Arduinio 'workalike' , but all the mechanical principles remain, regardless where the smarts come from.

Testing with a 3/4 imperial tap as hob...

Front panel control above is the final layout - change from prototype below..

Joe

Edited By Joseph Noci 1 on 28/07/2020 07:53:41

Youar set up looks really good Joseph. I hadn't seen it before, Is that an existing rotary table you are using? I was going to use a spin indexer as the basic structure and add a worm and wheel gearbox to it. I've just got the spin indexer and it looks well made and rotates with little friction. It takes 5C collets which go up to 11/8 so it would hold the gear blank on an arbour. I'm trying to find a suitable worm and wheel. Chinese ones don't seem to be big enough.

Hi John,

The rotary table is an EMCO table and the stepper/drive mechanics were added. Done initially as a versatile electronic rotary table, but the step to a hobber function was sort of logical.

Since the idea toted is for an Arduino to do the job, maybe the MEW article Neil mentioned is a good place to start.

My post was more to show how it could be used on a mini-mill with the bits, like the spindle encoder, just being 'strap-on' to do the job. A second stepper could be added to the X axis for auto feed - would double as a powered feed for the mill too!

Must admit I have never cut a gear in my life ( the plastic thingy above does not count), and probably never will..most times for me the fun is in building the tools!

Joe

EDIT:

While searching for the worms and wheels, etc, just do some sums first to see what sort of ratios are required - If the stepper needs to spin past 200-300RPM, the loss of torque will make your life miserable in lost steps, if you don't get the stepper sizing, friction and stiction, inertias, etc, quite correct..

Edited By Joseph Noci 1 on 28/07/2020 09:40:46

I'm getting worried about me. This is the sort of article I enjoy and I don't recall it at all. Yet Part 3 is bold as Brass in MEW295. Strange - I remember nothing after Machine of the Future. MEW clearly has a major Health and Safety problem if readers become forgetful after reading it! Perhaps shock and awe caused by seeing Andrew's Workshop in print triggered my amnesia. When I find my glasses I shall sue.

Seriously though, the quickest way to get a project working is to buy one or copy an existing design. But that removes learning opportunities, all the fun of solving problems, and the pleasure of making it yourself. And as I'm discovering, it's a good thing to keep the old brain active...

The other implementations are very helpful if John and I carry on, for example, I've been twitching about how to input ratios, when Joe and Toby both display number of teeth.

Toby's article makes an important point about EMC, an issue largely ignored in most workshops. His first hobber prototype failed because of interference generated by the lathe motor and speed controller. It discombobulated his Arduino, feeding the poor thing so much electronic muck it had a nervous breakdown.

Just an example. A project like this might need to solve a range of engineering problems: software, electronics, signal and control. On the plus side it eliminates a lot of mechanical complexity and opens the door to software bells and whistles. Model Engineering reminds me of Clausewitz: 'In War everything is simple, but even the simple things are difficult.'

Dave

Joseph, thank you for the point about stepper motor speed . I did the calculation and the worm gear is no use. E.g. cutting 10 tooth pinion, Hob running at 300 rpm, the blank has to rotate at 30rpm, max gear ratio for 200 rpm stepper is around 6:1. So need to go toothed belt drive route.

Maybe we should "unask the question"? Why an Arduino, indeed why a processor at all? There was an excellent design for a hobbing controller some time back, I think the late great Sir John had a hand in it, that used a hardware divider programmed by thumbwheel switches to count down pulses generated from the milling spindle, using a high res encoder with a frequency doubler. That's a good approach except for needing the encoder.

I suggested a while back that the high res encoder could be replaced with a low res one (possibly even 1 pulse per rev) and a phase-locked loop with another divider to multiply up the pulse frequency coming from the spindle sensor. Then you have two division rations to play with to get the right ratio. I even got as far as ordering the programming switch but it's another project for the pending pile...

I like the idea of interpolating extra pulses with a phase locked loop, fiendish!

The disadvantage of hardware is build complexity and lack of flexibility. Adding features and fixing mistakes could well mean redesigning the whole board. Hardware is designed to do one thing and that's it. Rigid and expensive.

I see microcontrollers like the Arduino as a sneaky alternative. Rather than designing and building many different fixed bespoke logic circuits, a microcontroller is just a bunch of inputs and outputs that can be programmed to perform any logical combination. For a few quid an Arduino can be a tachometer, teleprinter, hobber, divider, stop watch, missile guidance system, process controller, robot brain, engine management unit, temperature or whatever else the designer can squeeze into it. And if the program is wrong or new features are wanted, all that changes is the software. Cheap and flexible.

However computers can't be as a quick as a hardwired circuit, and ain't easy to have an Arduino keep up with a 4000 p/r rotary encoder spinning at 2000rpm. An interesting device that bridges the gap are programmable logic arrays, a sort of computer chip containing lots of independent logic elements that can be programmed to create conventional fast circuitry. Not a computer program with conditions and sequences, but millions of gates cross-connected to a goal by enabling them in an organised way. A grown-up and much more flexible version of the old Read Only Memory chips programmed by popping lots of internal fuses. FGPA technology is as fast, or faster, than conventional circuits and can be reprogrammed. Too difficult for me, I bet Joe Noci uses them all the time!

My first choice would always be a microcontroller because - provided you know how to program them - they're much easier to use than designing hardware. Circuit design, selecting devices, making PCBs and soldering lots of components are all hard work!

My main reason for not trying FGPA is fear it's too much to learn at my age. I'm already struggling with far too many interests.

Dave

THe late JS did start with a non computer system which is why 4000 pulses per rev were needed on the spindle encoder. He used a 2:1 belt drive to help. The stepper does 200 pulses per rev so followed by a 20:1 worm drive requires 4000 pulses. Thus 4000 pulses produced > 4000 needed. Place a divider in between and it adjusts it and is able to work at any (reasonable speed) and go backwards. This was possible with CMOS discrete chips back in the day but they became obsolete and difficult to get which is what drove JS to find someone who could do it in software.

The first problem with most of the micros with a 'high level' operating system is that they don't tell you that they go off and do their own thing every few milliseconds which interupts the flow.

A possible problem is that the PLL will not exactly follow speed changes within each revolution of the spindle. The bandwidth of the PPL cannot be greater than the data input rate. It's a fundamental axiom of signal processing to gather as much data as possible before extracting information. You can't magic information out of limited data.

A 4000 pulse encoder running at 2000rpm is 7.5us between pulses. Plenty of time for a decent processor to do the calculations. An ARM Cortex processor with onboard floating point and running at 100MHz can do hundreds of instructions in the time available. It will also have on board timer/counters that automate pulse counting or timing. These type of processors are a few dollars. Of course one needs to junk any operating system, but a simple interrupt driven loop should be fine, and largely deterministic.

I've just had a quick skim of the hobbing articles in MEW. A lot about building but nothing about design or specification.

I take no responsibility for any shock and awe suffered by SoD. It's probably just as well he only saw pictures rather than seeing it in reality!

Andrew

The nice thing about an Arduino is that it doesn't have a high level O/S to get in the way. So it does what you ask it to and not much more...

Just a thought. Sir John did a bit of work on gear hobbing and ended up using Linuxcnc... You could even start with the printer port... It is a cool platform/framework that allows for a ton of easy development.

Coincidently I've been looking at the possibility of using a RaspberryPi 3 or 4 and Rasbian Linux as a microcontroller. Advantages: a real operating system, multi-core 64 bit CPU, built-in GPU, FPU, wifi, usb, print support etc and cheap. The CPU in a Raspberry is considerably more powerful than both Arduino and Nucluo. Disadvantages: limited number of IO pins (about 40), delicate interface electronics, no easy access to hardware interrupts, and the default Completely Fair Scheduler (CFS) that causes Bazyle's impossible to predict interruptions.

CFS is the main problem: it's designed to share multiple tasks across multiple cores such that tasks don't get stuck. Basically tasks run in a time-slice allocated by the operating system and return to the queue when time runs out or they stop for any reason such as waiting for a disc drive. Tasks are restarted by CFS in a fresh time slice when whatever it's waiting for is available, or it rises to the top of the queue again. Although there's some notion of priority, the scheduler pays lip service to it, unless it's reduced! (You can volunteer to stay at the back of the queue.) Anyway, given a queue of tasks waiting for a time slice, CFS selects the task which has least time on the system so far and everything gets a fair crack of the whip. Works very well except when a program must run to a timetable or respond immediately to events. This sort of task needs to stay at the top of the queue without being mucked about by routine business!

The ideal answer is a Real Time Operating System, and there are some for the Raspberry for those with time to investigate. Bit too specialised for me. However, newer Linux Kernels come with scheduler options that might be 'good enough' for embedded work. The Deadline Schedule gives favoured tasks the priority they need to meet a deadline, FIFO does First In First Out, and Round Robin is FIFO with time slices. All these options override CFS and allow tasks to queue jump and dominate. Unfortunately they can't take the system over completely because Linux has other essential jobs, but - on a multicore CPU - they get close to running continually, behaving rather like a fast embedded microcontroller with short glitches.

The open question is, can a linux program with 4 cores available and top scheduling priority do better than an Arduino? Worth a try I think.

Not recommending Raspberry for John's Hobber. Nucleo is a very good choice if faster than an Arduino is needed, and the programming can be very similar.

Dave

All good points Dave and having recently got into Arduino after a lifetime as a hardware engineer I generally agree! However it seems to me much harder to emulate a PLL to do the interpolation between say 8 pulses/rev to the time precision needed for hobbing in software than just realising it in hardware, especially in an an Arduino with a 4 us cycle time. On an FPGA, not a problem, or in a faster processor.