[keitholivier]

Folks, I would like to convert a universal mill to CNC for the specific purpose of low volume gear hobbing. The machining spindle to rotary table axis must have a very specific ratio, which is dependent on the number of teeth to be cut on the blank. Some people do this mechanically using drive shafts, gear reduction and "master gears" for the specific number of teeth needed.

Others use a good rotary encoder on the spindle holding the hob and feed the encoder output directly to the input of the motor drive unit for the rotary table holding the blank, with fixed ratio gearing to step down the speed some amount that then allows them to use a specific master gear in the chain where the teeth on the master gear match the teeth that will be cut on the blank. This is to avoid the complication of having a computer control the motion.

The next possibility is to use a servo motor on the rotary table which is synchronised to the speed of the machining spindle and the speed ratio between the 2 axis is controlled via a CNC controller. This needs to be high reliability, similar to how an electronic leadscrew works on a lathe. So most of the discussion I have seen has been around Linux CNC which is considered to be better than Mach or other windows based software. But in looking at Linux CNC and its supported hardware, they start with printer ports (long obsolete) and then go on to PCI card based solutions but these would not be compatible with a NUC format computer (I would not like to run a big old desktop computer in this day and age...)...

So Centroid appears to bypass the entire OS limitation by using a dedicated computer optimised for motion control with what could be considered a real time OS. I can see how this should be much more reliable than anything running on a PC or Mac.

What I do not know is how the sort of synchronised motion is done for gear hobbing, where one needs a defined ratio between the 2 axis to form the gear. Would this be done by a specific G code function ? On the universal mill itself, its only the spindle speed and rotary table motion that is critical. The table is angled to the alpha angle given on the hob (for a spur gear), the spindle rotated at cutting speed and the rotary table speed will be matched according to the programmed speed ratio. Feed of the cutter across the gear can be done with a power feed or it could be a cnc axis (feed rate) and the Z axis defines depth of cut, could be manual, or another CNC axis.

If anyone has any insight, it would be appreciated. My plan is to buy a new small universal mill, so that one has an accurate mechanical system ($17500 and up for the Knuth universal mills) and then add just what is needed for gear hobbing, which seems to be the rotary table with servo drive and all the electronics and code to make that work. If I add servo control to the 3 main axis, it would allow the mill to be used as a small CNC mill when the table is set at 90 degrees to the saddle. The table should be more than big enough for the parts I have in mind which would be aluminum castings. Volume no more than a couple hundred parts a year.

[RaderSidetrack]

But in looking at Linux CNC and its supported hardware, they start with printer ports (long obsolete) and then go on to PCI card based solutions but these would not be compatible with a NUC format computer (I would not like to run a big old desktop computer in this day and age...)...

Perhaps you have overlooked LinuxCNC supported Ethernet interfaces similar to Mesa products? For example: 7I96S STEP/IO Step & dir plus I/O card

[keitholivier]

Perhaps you have overlooked LinuxCNC supported Ethernet interfaces similar to Mesa products? For example: 7I96S STEP/IO Step & dir plus I/O card

If I do that then I still have to bother with compiling and manually setting up a special version of Linux. If I can skip the Linux altogether and have the code run on a dedicated motion control board that would be better.

[joeavaerage]

Hi,

So Centroid appears to bypass the entire OS limitation by using a dedicated computer optimised for motion control with what could be considered a real time OS. I can see how this should be much more reliable than anything running on a PC or Mac.

No, the Centroid software runs on a PC that uses Widows as the OS. Windows is not in any practical way a realtime computing platform, so the movement data is communicated to the Centroid Acorn control board via a motion buffer of
several tens of milliseconds or even hundreds of milliseconds just like Mach, UCCNC etc.

I have a rotary axis on my Mach4 machine. It has a servo drive that allows very high resolution, higher than is practical if the truth be known. I have tuned it for 180 pulses/degree. Ergo the smallest movement I can
command with Mach4 is one pulse or 0.33 arc min. The servo reducer from the servo to the chuck has a gear reduction of 19.5:1 and has a max backlash of 2 arc min. I deem 2 arc min lash to be good enough
for any gears I would ever make!

For example a move like:

g1 x10 a3600 f 36000

causes the A axis (chuck) to rotate 10 times (3600 degrees) while the X axis advances 10mm. creating a 1mm pitch thread at a speed of 100 rpm, ie six second worth of movement.
This relies on any decent CNC machine that can coordinate movement between two (or more) axes. That one axis is linear and the other is rotary takes a little thinking about but its
is just as valid as the X and Y axes coordinating.

Certainly LinuxCNC allows you to programmatically slave one axis to another, but just the coordination of Gcode means that you don't actually have to do that...unless that is your wish.

Any decent software like Centroid, or Mach4 or UCCNC or LinuxCNC can be used to drive a gear cutting machine. Do you suppose any of these software solutions would have survived if they were not capable
of such basic stuff?. I rather think not.

Craig

[keitholivier]

Hi,

No, the Centroid software runs on a PC that uses Widows as the OS. Windows is not in any practical way a realtime computing platform, so the movement data is communicated to the Centroid Acorn control board via a motion buffer of
several tens of milliseconds or even hundreds of milliseconds just like Mach, UCCNC etc.

I have a rotary axis on my Mach4 machine. It has a servo drive that allows very high resolution, higher than is practical if the truth be known. I have tuned it for 180 pulses/degree. Ergo the smallest movement I can
command with Mach4 is one pulse or 0.33 arc min. The servo reducer from the servo to the chuck has a gear reduction of 19.5:1 and has a max backlash of 2 arc min. I deem 2 arc min lash to be good enough
for any gears I would ever make!

For example a move like:

g1 x10 a3600 f 36000

causes the A axis (chuck) to rotate 10 times (3600 degrees) while the X axis advances 10mm. creating a 1mm pitch thread at a speed of 100 rpm, ie six second worth of movement.
This relies on any decent CNC machine that can coordinate movement between two (or more) axes. That one axis is linear and the other is rotary takes a little thinking about but its
is just as valid as the X and Y axes coordinating.

Certainly LinuxCNC allows you to programmatically slave one axis to another, but just the coordination of Gcode means that you don't actually have to do that...unless that is your wish.

Any decent software like Centroid, or Mach4 or UCCNC or LinuxCNC can be used to drive a gear cutting machine. Do you suppose any of these software solutions would have survived if they were not capable
of such basic stuff?. I rather think not.

Craig

Thanks for the code example. Yet I think there s still a difference between Mach, which does all processing on the PC and under control of the OS (windows), and Linux CNC where the OS has been modified to act as a RT OS, thus allowing time critical processes to be more reliable. And then Centroid where closing loop on position is not done on the PC or under the centroid code that runs on the PC but instead is done on the dedicated motion controller that is totally independent of the PC.

Im pretty sure all commercial CNC machines use a variation of the Centroid approach by using dedicated motion controllers that are independent of the user interface or code generation system. Of course PCs have fundamentally become faster and faster over time, but due to the way the OS has developed, it could be argued also less predictable in terms of how processing priorities are assigned by the OS to various tasks. I believe that that is the reason why the modified Linux based code has become more popular and thus Linux CNC has offered features like rigid tapping and the "electronic leadscrew" for a much longer time than other solutions.

The commercial cnc controllers are obviously out of scope for my application since it would be too expensive for my setup. Im not going to rely on a windows based solution for motion control and the way Centroid packages their features I'm not certain it would be the right solution for the spindle/hob synchronization. But for 3 axis operation of the mill in non hobbing (3 axis) mode, I can see that the Acorn system is a neat solution. As Clough42 explains in his "proof of concept" video, the micro controller he picked had a co-processor for doing floating point math, hardware that reads the encoder and buffers the data without any polling by the main cpu. I have seen some applications with people using 8 bit micros and writing the code in assembly language, but that is some seriously hard core stuff. There are more, easier options today and the Freescale board he used that was loaded was only $32.

[joeavaerage]

Hi,

And then Centroid where closing loop on position is not done on the PC or under the centroid code

I'm sorry to say but I think you are mistaken about the Centroid Acorn, it is an open loop Step/Dir controller similar to Mach.

The same company does another controller, the Centroid Oak, and that does close the loop whereas the Acorn does not.

All that is required is that one axis is coordinated with another. That can be done by having one servo slaved to another, but that method is going the way of the Dodo.
This method requires a motion controller that can close the loop, and do so between two axes. Controllers like the Galil which do so are still available .

Modern machines are using variants of 'distributed motion control', protocols like Ethercat, ProfiBus, CANOpen and others.

The essential idea is that each servo (or axis) is responsible for executing the movement that it is instructed to do from the master. If for instance the A axis is instructed to rotate
0.2 degrees in the next 1 millisecond, then that servo does that. At the same time another servo, a linear axis is instructed to move 0.44mm in the .next 1 millisecond.
Each servo knows what its supposed to do, and gets on with it but has no knowledge about what the other servo is doing, or even that is there. At the end of the 1 millisecond
both servos will report their actual position to the master. If one or the other servo has not faithfully executed its commanded move the master will know about it and fault out.

The upshot is that EACH servo drive is becoming smarter and smarter and can handle generating its own motion.

This is contrary to your notion that some central processing node must have control. This is very much what used to be done and controllers such Galil facilitated that but all
the latest and greatest CNC machines are using Ethercat or some such distributed motion control.

In lots of ways its like an extension of an open loop control like Mach. Mach issues movement instructions and the machine is expected to carry them out, and barring a fault
it does. If you are of the opinion you need a central controller to 'supervise' you are tacitly saying that you expect the machine to fail to execute faithfully movement commands
it is given and therefore needs some central control. Surely that is a sign of a machine incapable of doing what is asked of it? Is that faulty thinking?

I think you are leaning towards having one axis slaved to another to ally your qualms that one axis will in some way lag the other....instead of building an axis, well all axes
actually, that will do as they are commanded to do 99.999% of the time, and fault out the other 0.00001% of the time.

I have now quite a number of rotary toolpaths where the A axis must maintain perfect synchronisation with at least one, but often all three linear axes, and such tool paths execute
perfectly. All my axes, both linear and rotary are servo driven and if any one of them lags its commanded position by greater than it 'following error window' it faults out causing the whole
machine to shut down. My linear axes have a 'following error window' of about 0.015mm (linear equivalent). Thus if any one of them gets out of synch with respect to the others it faults.
To be honest I have not calculated the 'following error window' for the rotary axis.

In the several months I've been using the A axis I've never had an 'out of synch fault' or 'following error fault'. You'll have to decide then whether an open loop solution like Mach is
good enough to satisfy your qualms or whether you want a feedback capable realtime contoller....at whatever that costs.

Craig

[joeavaerage]

Hi,
the Acorn is $329, the Oak is $1395.

It is not clear whether the Oak can slave one servo to another even if it can close the loop on any given axis.

PS
By the way I realise I have misquoted my A axis. Mach4 is set up to produce 250 pulse per degree of A axis motion, ie a resolution of 0.24 arc min.

Craig

[RCaffin]

Just plain threading is a bit similar, and a lot more complex than you might think.
When the tool tip hits the metal at the start of a thread, the spindle slows a bit. It can't help it.
By and large the response of a PC to such slowing is far far too slow, and just won't work. Spindle power supplies can't handle that either.

The ESS with the latest driver handles the slowing of the spindle quite well. It does not try to adjust the spindle speed; rather it matches the speed of the Z axis to the immediate current speed of rotation of the spindle.

So as various people have suggested, these days the fine control is done by an external motion controller, not by the PC.

Cheers
Roger

[joeavaerage]

Hi Roger,
I argue somewhat differently.

Lets say a servo is commanded to move a certain distance in a certain time, and that move must counter both acceleration and counter cutting forces say.
This might be a lathe spindle for instance. As the thread is started the spindle might be expected to slow somewhat. But if this is a servo then it will react
virtually instantly to any change of load and dig into its reserves and catch up.

Modern AC servos have torque bandwidths of 5kHz and more, velocity bandwidths of 1kHz and more for position bandwidths as high as 500Hz. This will mean that if any
cutting load, for instance a lathe tool engaging the material, the current will increase in the servo within 200us (approx 1/bandwidth or 1/5000 or 0.2 milliseconds).
If the steady state spindle speed is 1000rpm, then 200us represents 1.2 degress of rotation, the servo is already in catch up mode. I would argue that if a modern AC servo
is used its dynamic response to a change in load is very VERY rapid indeed. In fact is is the same sort of response that you might expect from any high bandwidth feedback
control loop.

If lets say as OP is interested in a rotary axis is 'slaved' to another axis, say a linear axis as might be used in cutting a helical gear for instance. If the rotary axis slows at all,
it will cause a concomitant reduction in speed of the linear axis as well. This is what he desires so that the rotary axis stay precisely synchronised with the linear axis.
The response of the slave axis (linear) is not instantaneous, the master axis (rotary) must first detect its loss of speed, that starts a calculation as to how much to slow the slave,
and then that correction fed into the velocity loop of the slave axis. In short I would expect the delays associated with that coirrection to be the inverse of the bandwidth,
ie 1/5000 or 200us. The same damned number!!!!

This was from OP:

OS has been modified to act as a RT OS, thus allowing time critical processes to be more reliable.

I actually wanted to say 'rubbish' but it did not seem polite...at least without explaining why I thought so. But the explanation I have just given is that a servo operating in feedback mode
with its own matched driver has a bandwidth, at least as high and in many cases higher bandwidth than a realtime computing platform like LinuxCNC.

What I think is rather poorly understood about servos and their matching servo drives is that they form a feedback loop that is at least as good as any realtime computer and in many cases better.
The servo and servo drive are made by the same manufacturer so the drive is perfectly matched to the servo. As an example my Allen Bradley servo drive has a piecewise linear approximation of the magnetic
saturation of the servo. Have you ever heard of a feedback model that incorporates non-linear effects? I bloody bet not!!! Thus the Allen Bradley drive will do a better job of controlling the servo
than LinuxCNC or any other general purpose realtime computing platform UNLESS you are prepared to generate the data required for the non-linear feedforward correction. Good bloody luck!!

Quite frankly I'd rather rely on two of my Delta servos remaining in synchronization despite differing loads on each servo by virtue of each servo having a closed loop torque bandwidth of 5kHz.
Linux CNC could not even come close to that. So OP I'm sorry to say that I think your assertion that a master-slave relationship is preferable is pure bunkum. Bunkum was a favorite phrase
of Prof Bargh who taught us all this s***t all those years ago.

Craig

[RCaffin]

Hi Craig

I have not used a modern AC servo, so I will plead ignorance here. But even so, running a threading tip into a 50 mm diameter steel bar is going to require a huge surge of power from the driver. Would an AC servo driver be able to respond that powerfully that fast? I guess a 10 kW unit might do so, but what about a
hobbyist-level drive? I don't know.

OS has been modified to act as a RT OS, thus allowing time critical processes to be more reliable.
Maybe the key words here are 'more reliable'?
But even so, a dedicated (FPGA?) controller is very likely to be better.

Mind you, how many hobbyists can afford a cluster of AB drives ? I can afford some Gecko ones . . .

Cheers
Roger

[joeavaerage]

Hi,

Would an AC servo driver be able to respond that powerfully that fast?

Yes, that is what bandwidth means. Its not new either, DC servos of yesteryear also did well, maybe not 5kHz, at least not cheaply....but that is what bandwidth means.
It is a measure of the time taken for the system to respond to a disturbance.

I am a hobbyists and I have five 750W Delta servos on my machine, or until I finish my fifth axis, four servos and one waiting to be fitted. The rated torque for a 750W Delta servo is 2.4Nm,
and overload torque is 7.1Nm. I would expect any one or more servos to go from idling along at 0.5Nm to 7Nm in response to a sudden increase in load within two time constants, with the time
constant being the inverse of the torque loop bandwidth, ie 5kHz. Thus the time constant is 200us.

So I would expect any of my servos to go from idling along to max output in 400us....which I think you'll agree is pretty damn quick. I would expect no better, nor even as good, a response
from a realtime computing platform.

These servos cost me $438USD each....so not cheap exactly but so much performance for the sum expended.

The microcontrollers inside a servo drive are very impressive. I'm using a Texas Instruments TMS320F2069M micro controller for a servo drive I'm making. These things are bloody great,
single cycle 32bit floating point multiply and accumulate, nine highly configurable PWM peripherals, in fact peripherals up the Yazoo, running at 90Mhz, and all for under $20.00USD.
These things are just made for polyphase rotating machinery and I don't believe there is a general purpose computing platform that can close the loop that comes within a bulls roar of these things.
It is controllers like this that have made modern servos as good as they are...back in the nineties they would have been so expensive, only the military need apply, but now they're everywhere.
Even the cheapest crappyist of Chinese servos has one of these controllers inside that can close a feedback loop with vastly greater precision and speed than we can imagine, and all for less than a
'feed of fish and chips'.

Maybe the key words here are 'more reliable'?
But even so, a dedicated (FPGA?) controller is very likely to be better.

For my money I'd rely on one of these purpose-built microcontrollers before I relied on any computing platform....mind you that because I've programmed them and de-bugged code to run
a Field Oriented Control algorithm and can personally attest to just how potent they are. If you've not been up close and personal with one you might be forgiven for not realizing what a game
changer they are.

It is that lack of knowledge that means that many believe that 'full close loop control' must be done by a realtime computer like LinuxCNC or a reatime controller like Galil when in fact a humble,
cheap, 32bit microcontroller can 'hold them to the flames', at least for rotating polyphase machinery.

Craig

[RCaffin]

Hi Craig

I am using Baldor DC PM motors on the spindles. They are extremely robust: I have run one at 4x rated current once when I was drilling into titanium and forgot to change the speed & feed. Oops moment, but zero harm done. Huge thermal inertia.

Now, I dare say one of them could handle a huge power surge, but the DC supply (micro-processor controller SMPS) has a very limited bandwidth: effectively about 1 second time constant. So mine is very different from yours there.

Having started life with a 1st-gen PDP-8 and an IBM 7044, things have changed. Great fun.

Cheers
Roger

[joeavaerage]

Hi,

Now, I dare say one of them could handle a huge power surge, but the DC supply (micro-processor controller SMPS) has a very limited bandwidth: effectively about 1 second time constant. So mine is very different from yours there.

yes servos, even older DC servos are great, and they don'tcome more robust than Baldor. I hear they gather up the old Baldor servos and melt them down to make Abrams M1 tanks....probably myth!
Imagine now that the Baldor servos you have are driven by a high bandwidth servo drive......that would make them extremely potent devices.

Even el-cheapo Chinses servos have bandwidths in the 5kHz (torque) class......back in the eighties these would have been considered state of the art....now they are commonplace. Most people
don't know just how higher performance a modern servo is capable of.

Craig

[RCaffin]

Hi Craig

Well, yes, but . . . my machine can and does make good threads with the ESS and the latest power drive. Changing the drive would cost me $$.
For a new build, it might make sense.

Cheers
Roger

[joeavaerage]

Hi Roger,
yes the ESS does OK, but could at best be considered to have a velocity bandwidth of about 20Hz, which is OK for threading, but I think this OP is wanting/needing
a level of precision at least one order of magnitude better, maybe as much as fifty-fold better. With decent servos he can have that....or he can use a realtime
computer/controller which will at best only match a good servo.

Either solution will work with nothing much to choose between the performance. From a simplicity point of view, servos win that battle handily. Even with LinuxCNC
or Centroid Oak or Galil h'ell still need servos, so from a cost point of view servos are better also.

The essential point is that ANY feedback control loop can have a bandwidth no greater than the bandwidth of the limiting element. If servos have a torque loop
bandwidth of 5kHz, and either solution, ie servos alone OR LinuxCNC as a supervising controller of the same servos can NEVER be better than the servos, ie 5kHz.
Even if LinuxCNC (or Centroid Oak or Galil) is magic it can still never be better than the bandwidth of the servos it controls.

Craig

[RCaffin]

Reverting to the original request:
I can't really see any problems. I have made gears using three different methods.

The first laid the blank flat on the table and milled out the teeth with a fine end mill. The method is suitable for clock gears etc.
I can't find any photos of this.

The second used a custom gear hob in the spindle with a simple rotary table.
Attachment 492446

The third use the simple rotary again and milled out the tooth profile using a ball end cutter.
Attachment 492448

Mostly these were making GT2- compatible pulleys, which were used to drive the Z axis.
Attachment 492444

If you want a helical gear the third method will still work fine: you just need a little more programming.
Incidentally, the cutter in V3 was a 1.1 mm ball end spinning at 3000 rpm, with MQL mist spray. Movement (feed) was a shade slower than normal (I wonder why?). Apart from a simple good rotary axis, nothing special was needed.

Yes, I know this may not be how gear hobbing is done conventionally, but so what?

Cheers
Roger

[joeavaerage]

Hi Roger,

Yes, I know this may not be how gear hobbing is done conventionally, but so what?

I've been called many things but 'conventional' does not figure on that list. I say good work to employ a method to exploit the capability you do have....and 'devil take the hindmost'.

Craig

[keitholivier]

I see that Mach 4 now uses an external motion controller too. So far I cant figure out which one, artsoft does not seem to sell any. All I can tell you was that Linux CNC supported critical applications like rigid tapping and threading long before Mach did. Obviously the commercial Centroid CNC controllers did too. I have been trying to find a feature sheet for mach 3 and 4 amongst the PDF files but have not identified it yet. The industrial license for Mach 4 is pretty expensive at $1400, so far I dont know what it gives you that the regular version doesnt.

It seems that as the capability of the hobby cnc solutions rises, they look more and more like "real" cnc controllers and cost more too. I suppose that is not very surprising.

[keitholivier]

Reverting to the original request:
I can't really see any problems. I have made gears using three different methods.

The first laid the blank flat on the table and milled out the teeth with a fine end mill. The method is suitable for clock gears etc.
I can't find any photos of this.

The second used a custom gear hob in the spindle with a simple rotary table.


The third use the simple rotary again and milled out the tooth profile using a ball end cutter.


Mostly these were making GT2- compatible pulleys, which were used to drive the Z axis.


If you want a helical gear the third method will still work fine: you just need a little more programming.
Incidentally, the cutter in V3 was a 1.1 mm ball end spinning at 3000 rpm, with MQL mist spray. Movement (feed) was a shade slower than normal (I wonder why?). Apart from a simple good rotary axis, nothing special was needed.

Yes, I know this may not be how gear hobbing is done conventionally, but so what?

Cheers
Roger

Roger, I will be making gears that need to run at 120+hp sustained with input shaft speed of up to 5800rpm. So the gears will need to be hobbed in a pretty rigid setup with minimal lash and then hardened and tempered etc. Depending on how loud they are, may need to be ground or shaved after heat treatment when the surface hardness is in the 58-60Rc range. There are likely to be splines on the input and output shafts too, to accept input and output flanges.

[joeavaerage]

Hi,

I see that Mach 4 now uses an external motion controller too. So far I cant figure out which one, artsoft does not seem to sell any.

I use an Ethernet SmoothStepper by Warp9TD, $195.00USD, as does Roger if I'm not mistaken. Artsoft, now actually called New Fangled Solutions, does not manufacture motion boards. There are a half dozen
credible manufacturers of Mach ready motion boards, not counting the swag of somewhat less credible Chinese motion board manufacturers. Artsoft has NEVER made hardware.

All I can tell you was that Linux CNC supported critical applications like rigid tapping and threading long before Mach did.

I disagree, Mach predates LinuxCNC. LinuxCNC grew out of EMC2 many years ago, and one of the EMC2 developers, Art Fennerty, branched out and wrote the parallel port driver for Windows which started
Mach and hobby CNC. LinuxCNC came later. Given that LinuxCNC is quasi-realtime, it can be a feedback controller, whereas Mach requires certain work arounds to achieve the same result.
It is fair to say that LinuxCNC supports rigid tapping etc 'natively' whereas Mach uses both realtime motion control features or the feedback features of servos, or even more recently Ethercat, a
distributed motion control set up.

You may choose to disbelieve when I say that with AC servos and Mach4 you can achieve perfectly synchronised motion....but I achieve that daily, to the limit of the accuracy of my machine, say 0.01mm.
I rather doubt my machine would be considered accurate or rigid enough to make highly loaded gears such as you describe, but I certainly believe Mach is at least capable of the task.

Obviously the commercial Centroid CNC controllers did too.

That's nonsense, Mach predates Centroid by a decade or more.

The industrial license for Mach 4 is pretty expensive at $1400, so far I dont know what it gives you that the regular version doesnt.

Virtually nothing. The main thing you get with Industrial is the 'Red Carpet Treatment' from NFS. You also get parametric Gcode programming called MacroB. It has
no more axes, or motors, or is any faster or more accurate or anything else. MacroB is used industrially but it does nothing that regular Gcode cannot but has things
like conditionals ('If' and 'While' loops) in Gcode for example.

Mach4Hobby costs $200USD, one time purchase, that allows up to five separate machines to be licensed, and as many demo copies as you require.

Craig