Arduino Gear Hobber

[John RutzenParticipant @johnrutzen76569]

[John RutzenParticipant @johnrutzen76569]

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.

[Martin ConnellyParticipant @martinconnelly55370]

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

[SillyOldDufferModerator @sillyoldduffer]

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

[John RutzenParticipant @johnrutzen76569]

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.

[SillyOldDufferModerator @sillyoldduffer]

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

[Anonymous]

Posted by SillyOldDuffer on 27/07/2020 21:32:14:

Fairly simple?

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

[Neil WyattModerator @neilwyatt]

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

[Joseph Noci 1Participant @josephnoci1]

 

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

[John RutzenParticipant @johnrutzen76569]

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.

[Joseph Noci 1Participant @josephnoci1]

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

[SillyOldDufferModerator @sillyoldduffer]

Posted by Neil Wyatt on 28/07/2020 01:45:41:

Err…

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

Neil

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

[John RutzenParticipant @johnrutzen76569]

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.

[John HaineParticipant @johnhaine32865]

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…

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 28/07/2020 12:07:06:

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

[BazyleParticipant @bazyle]

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.

[Anonymous]

Posted by John Haine on 28/07/2020 12:07:06:

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.

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

[Roger WhiteleyParticipant @rogerwhiteley62172]

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…

[sam sokolikParticipant @samsokolik60334]

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.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Bazyle on 28/07/2020 14:26:55:

…

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.

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

[John HaineParticipant @johnhaine32865]

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.

[John HaineParticipant @johnhaine32865]

Posted by Bazyle on 28/07/2020 14:26:55:

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.

Nothing obsolete about CMOS discretes – TI list a full range for one.

Yes, with a PLL you need more than 1 ppr to follow the spindle speed variations. But say a 100 or 200 line encoder is a lot easier than a 4000 line one.

[sam sokolikParticipant @samsokolik60334]

Posted by SillyOldDuffer on 28/07/2020 16:04:08:

Posted by Bazyle on 28/07/2020 14:26:55:

…

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.

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

I have been playing with linuxcnc on the RPI 4. Linuxcnc requires a realtime kernel. (in this situation – rt_preempt)

The thing with linuxcnc is you get a whole bunch of realtime building blocks. Like step generators with vel and acc limits, pwm generators, logic and tons of other pre-built realtime components. (plus you can make your own)

All of these components have been tested and are done

This was done on a RPI 4 With a custom realtime component – slaving the axis to spindle rotation. (well – most all the latest videos about the green machine are done with the rpi)

[Joseph Noci 1Participant @josephnoci1]

John Rutzen said:

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.

True, to a point – I made the encoder a quadrature encoder so that I can sense direction as well – not really needed. So, if a Quad. encoder then you can use a 1000PPR encoder, which will give 4000 pulses per rev. That will 'limit' you to around 10 tooth gears as a minimum.

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.

Also true, to a point. The power needed when running is low. However, the power must be sized to cope with the stepper acceleration requirements in relation to hob RPM, hob, pitch, and how quickly the hob reaches terminal speed. The key here is to ensure the best stepper acceleration possible.

To achieve that, you should feed the stepper driver with as high a supply voltage as possible – dV/dT must be large to overcome the stepper's inductance preventing current to flow for a short while..This really means try feed the stepper driver with at least 50v, even 60 to 70v if possible. Also run microsteps – go for at least 800 steps/rev, 1600 is even better. The microsteps are not to improve positioning accuracy, or even resolution ( it does not do any of those actually..) – microsteps help get past those low-end resonances as well.

You should also reduce mechanical inertia where you cannot control it – large driven pulleys, etc. Excess friction is a no-no, but some friction can be your friend – it helps stifle stepper resonance at the low end while accelerating.

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.

And also true, but maybe I scared you too much with my stepper speed warning! Steppers tend to lose steps for two reasons – At the low speed end – 4/5 rpm and up, to maybe 12/15 rpm – they suffer self resonance and this is where the greatest possibility of losing steps lies. At the high speed end – 200/300 rpm and up – maybe up to 800/900 rpm, steps will be lost if the stepper torque runs low – as the stepper increases in speed, so the torque decreases and its not linear! An 8 amp NEMA-42 stepper running at 1200rpm has lost nearly 90% of its sub 10 rpm torque.

Supply voltage plays a huge role in acceleration, and in high speed torque. A stepper supplied with 40v, will probably not run much past 400rpm AT VERY LOW LOAD. At 80v supply, it will supply that same torque at maybe 900rpm.

Back to the hobber-

What do we need in terms of driven blank/stepper drive ratios, versus hob pitch, etc.

Lets assume a hob rpm of 350 for these cases.

Well, for a Mod 0.8 – 10 tooth gear ( 8mm diameter blank – more or less..), the blank rpm = 35.

For a stepper/blank drive ratio = 40:1 – stepper rpm = 1400, for a ratio of 20:1, stepper rpm = 700.

For a Mod 0.8 – 150 tooth gear ( 120mm diameter blank) – the blank rpm = 2.3

Stepper rpm = 92 @ 40:1 ratio, and obviously, 46rpm @ 20:1

So you need to find a 'sweet spot' in drive ratios.

But, there are few tricks one can play to get past the resonance problem – Use high voltage drive, fit a flywheel to the stepper drive shaft – an aluminium disc, 55mm diameter, 15/20 mm thick, for a nema-23 motor is good – add a bit of friction to the blank drive shaft – eg, a felt pad that presses up a disc ( disc brake..) fitted to the blank drive shaft..

Or, fit a rattle damper to the stepper drive shaft – that will cure almost any resonance problem! I won't go into rattle dampers here – somewhere on the forum are my lost posts on teh subject..

What did I do? – My rotary table worm drive dictated the ratio – 40:1. I used a double stack nema 23 motor. I drive the motor with 75volts. The encoder is a 1000PPR quadrature unit.

The reason for a double stack motor – a nema 34 would be good for the torque curve, but is has much worse resonance issues with acceleration, mainly due to the larger rotor diameter. The nema 23 single stack ( square motor size) has a poorer torque performance and is marginal at 400 rpm drive on my rotary table ( with rattle damper) . The double stack motor offers almost the same torque as the single stack nema 34, and works well at 800/900 rpm with the rattle damper. Acceleration is very good.

So, I would suggest, go for a 30:1 to 40:1 ratio, use a double stack nema 23 motor, at 60 to 70 volts, and fit a rattle damper. That will give you a no nonsense solution with very good performance.

Anything down from this spec will also work, if you are happy to just go a little slower, halve the hob rpm, slow down on the feed, etc, and it will work!

[Joseph Noci 1Participant @josephnoci1]

Now, that previous post was a long one…

Hers is a follow on, a little shorter..

On the software side – I would not go the route of PLL's, etc – a little too fiddly, and rather difficult when you want to add features or functions, esp if adapting a rotary table to do hobbing – a little more software makes the table dance all sorts of jigs – angular steps size increment, turns at specific RPM's, etc, etc. For a dedicated hobber, less so, but still , in my opinion, a lot easier to get to work, and modify, and add more gear tooth options, etc..

My software is very similar in operation to the ELS system I did for my lathes –

The Encoder gives pulses that are directly related to the angular position of the hob. We need to rotate the blank periphery at a rate that matches the rotational pitch rate of the hob.

The hob encoder gives 4000 pulse per rev. Lets say we have a hob pitch, and a gear blank number of teeth setting, that, with our stepper setup, means I have to give the stepper 1000 steps pulses to advance the blank by one hob pitch.

That's easy – Since the hob gives 4000 pulse / rev, and that's one tooth pitch, and that's 1000 stepper pulses, we simply place a divider between the hob encoder and the stepper pulses – divide by 4 and everything works! However, the divisor needs to cope with a myriad of ratios, many giving divisors with a remainder…

So I use a device known a Bresenham's line draw algorithm. this is a neat bit of math that generates a pulse train that is a result of interpolation of the present hob pulse and the desired stepper pulse, in a perfectly synchronised manner. Errors do not accumulate, and are averaged out over the 4000 pulse input pulse train.

It's simple and elegant, and works!

A 16MHz Arduino might however be a little pressured to do all this at the highest rates –

For a 10 tooth gear and hob rpm = 350:

hob rpm 350 – 6 revs/s = 24Khz pulse train from encoder ( 24 KHz interrupt rate)

Stepper RPM @ 40:1 ratio = 1400 (!) = 24 rev/s

Stepper pulse train, @ 1600 steps/rev – 24 revs/s * 1600 = 37KHz.

And then the processor must still execute Bresenhams, and do whatever else you want it to – monitor pushbuttons, etc.

However, the Arduino will do just fine if you are content to go slower, feed slower, etc…

Joe

(whew..)

 

EDIT – WRT Rasp-Pi – a huge overkill and a massive complication for noobs – have to contend with an environment that is so not machinist…

           WRT an operating system ( of ANY sort) – also a total overkill for these what amount to rather simple applications. An OS NEEDS to be deterministic for these applications, and good, solid RTOS's for these small end systems are notorious in their inconsistency, both in event sequencing and timing. Fine if running a 2GHz processor – a 100 cycle latency is around 50picoseconds and is is not really going to be noticed. 20 cycles at   16MHz WILL be noticed at a 16MHz processor clock, when trying to synchronize Encoder inputs, stepper pulse outputs, and Bresenhams..There is NO reason for an OS in a single function simplistic embedded system. There is even no need for an OS in complex single function systems, but rather the need for a scheduler.  I eventually even won that argument with BAe…

Edited By Joseph Noci 1 on 28/07/2020 22:44:04

[Author]

Posts