Freesteel Blog » Machining of brass again

Machining of brass again

Saturday, January 2nd, 2016 at 12:39 pm Written by:

Yes, it’s been a long while since I’ve done any blogging. Xmas, New Year, lots of stuff not working, and no interesting holidays to speak of.

A lot of time has been wasted meddling with these horrible Leadshine servo drivers that have the ability to program and measure their performance through a serial port (from Windows), but you can’t reset them when they’ve entered an error mode. The box of electronics is too compact and there’s no toggle switch to turn them off and back on again.

Then there was another two week delay narrowing down and investigating a weird motion effect that was all due to a loose grub screw.

Anyhow, here’s the video of the small part I made yesterday

Here’s what it looks like in the light:

I’ve got a lot of questions to chase up about the errors and marks on the part. It’s all done using my own code written in Python, but don’t try to use it as it’s all twistcodewiki driven, and I’m already forgetting which functions I need to call to make it work.

A note about the “correct” feed and speed mentioned in the video.

Recall that, after 20 years writing the software that generates CNC toolpaths, I’d not ever operated a machine or worked with someone operating a machine in that time period. I’m not unusual among my programming peers. This is an outrageous state of affairs, and tells you everything you need to know about the effectiveness of all those layers of businessmen, managerial staff, supervisors, and resellers who have inserted themselves like slabs of toffee between those who write the software and those who use the software. Even if I wasn’t interested in operating a machine, someone should have forced me to spend some time making at least one thing to a standard of quality at some point in my career as it would have paid off enormously.

The upshot is I don’t know what I’m doing and I don’t know what’s right. Searching for feeds and speeds on brass produced the HSMWorks CNC book. Unfortunately it’s all in Inches.

The calculations are as follows:

Cutter diameter 6mm = 0.236inches
Number of blades = 4
Brass SFM (Surface feet per minute) = 175
Brass IPR (Inches per revolution) = 0.002
Spindle speed = SFM/circumference = SFM*3.82/diameter = 2832 revolutions per minute
Feedrate = Spindlespeed*IPR*blades = 22.656in/min = 575mm per minute

As I’ve generally been coding F800 into all my toolpath files, I dragged the speed override slider to 71% on the linuxcnc interface after dialing down the spindle.

The spindle was much slower and the motion much faster than I felt would be right (it was actually kind of scary), but it ran quieter and the results were smooth.

The most important part of the calculation above relates the ratio of the feedrate over the spindle speed to the optimal chip size.

So how come, given that the feedrate of an operating tool varies as it slows down to go round corners and accelerates on the straights, the spindle speed is always hard-coded to a constant value and not set as a ratio to the actual feed rate during run-time?


Is there anyone in the business who has an answer to this question?

Clearly the calculations above provide the optimal values, and clearly everyone has gotten away with running outside of this optimal setting for part of the time. And maybe this was forgivable in the past when the controls and the spindle motors did not have the technical capability to vary themselves. But come on folks, the tech should be up to it these days.

What’s the problem?

Too many managers in between the programmers and the users who can’t see the commercial viability of investing in such a blatantly obvious and productive feature? It doesn’t look very hard to do from a technical stand-point, does it? I look forward to hearing their excuses.


  • 1. Dave Turner replies at 2nd January 2016, 4:01 pm :

    I wasn’t aware that modern CAM programs actually accelerated/slowed down feed speeds depending on whether they were going in a straight line or not. All the CNC stuff I ever did had a fixed spindle speed and feed rate for milling programs and constant surface speed for turning (although surface speed makes far more sense with the tool permanently in contact with the workpiece). In my experience surface speeds are only a vague guideline in any case, particularly if there interesting cutting insert geometry.

    As for the desire to insulate programmers to the users, I’m with you. Mumble-mumble years ago I was a MoD student engineer. Before we were let loose on the rest of the organisation, we had around 1000 hours of machine shop practice, 500 hours of fabrication (welding/sheet metal) and 500 hours of electrical and electronic assembly. The thinking then being that you wouldn’t be designing things that were impossible/horrendously expensive to manufacture.

    Now I see graduates with lots of hours on CAD but only the barest minimum of workshop time necessary to meet the requirements of the professional institutes.

  • 2. Julian replies at 2nd January 2016, 4:58 pm :


    It’s not the CAM programs the vary the feed speeds, it’s the controllers that do it, particularly with high speed machining where there’s too much momentum (as I’ve been told). See for example this vid where there is a noticeable dwell as it goes round those inner corners:

    I could never find anyone who made these machines to tell me the parameters of this slow down. It’s either responsive to the forces encountered by the machine (so it would go slower with a heavier piece), or merely programmed into the controller in its trajectory planning to limit the acceleration at any point to a hard-coded value.

    In LinuxCNC it’s the latter because it’s an open loop controller which generates pulses as input to the servo motor drives.

    Since the method algorithms in the controller for slowing and speeding the feedrate are not generally known, it’s completely impossible to develop CNC code to optimize against it, so no one bothers.

    I think the reason why the guys who develop the software (like me) get away with having none of the practical experience that ought to be required, is that we enter our careers accidentally (unlike engineers who were at one time student engineers). This is a fact of life in the software world.

    And then you’re in a place programming 9-to-5 where you appear to be productive over a number of years, and the knowledge deficit doesn’t appear to be enough of a problem to the managers to justify taking you off the coding job for the few weeks it would take to remedy this matter. There’s no vision of how much better things could be, and it’s all too short term.

    Maybe there’s the fear that the employed programmer will find metal bashing a lot more fulfilling than coding when it comes down to it, so it’s better not to give them the experience.

  • 3. Bob Warfield replies at 2nd January 2016, 10:03 pm :

    Much of what’s involved with feeds and speeds has to do with worst cases. Back before there were HSM constant engagement toolpaths (such as your own clever algorithm), there were folks who tried to dynamically vary feedrates as the cutter went into corners. The chief problem was the acceleration available to machines was just not very great, so this would tend not to produce as big of an advantage as was hoped, though it did produce advantages. But the HSM toolpaths were much better. Still, there are worst cases involved. When most manufacturers specify the recommended feeds and speeds for their cutters, they do so under the assumption that a constant engagement toolpath will NOT be used–hence the HSM rates can be much higher because that was a very worst case assumption indeed.

    BTW, the calculations above still don’t actually provide optimal values. MANY more variables must be considered. For example, your cut width may be such that radial chip thinning is a factor. Various penalties must be provided for chip clearance issues if either too much width or too much depth of cut is in play. The list goes on for quite a while. Our own Feeds and Speeds Calculator, G-Wizard, considers on the order of 50 different variables before making a recommendation.

  • 4. Dave Turner replies at 3rd January 2016, 7:24 am :

    I’d imagine it’s a hard-coded value as that’s far easier to implement than somehow relying on feedback from the device – by the time you’ve realised the problem, you’ve probably already either overcut or put huge chatter marks into your final pass. I suspect the limits are very conservative too. There’s a lot of inertia in the bed of a decent machine – there’s nothing quite like a huge chunk of cast iron to damp out vibrations.

    It would be interesting to see what would happen if you switched to full software control deciding acceleration instead of the controller middleware. I think you’d need a lot of test cuts in various materials with tools of varying diameter and depth to work out what the maximum acceleration could be. I suspect it’s enough of a 3d surface that the machine manufacturers say ‘f$ck it – we’ll stick to hardcoded acceleration values and have done’. Certainly it’s cheaper – which is of course good for the bottom line but doesn’t allow for evolution.

  • 5. Julian replies at 3rd January 2016, 11:10 am :

    Luckily I’m using an open source controller, so it’s possible to make some advances.

    This is the trajectory planner in LinuxCNC with the trapezoidal velocity.

    The thing is — since there is no feedback from running of the machine itself — this entire trajectory and kinematics of the machine could be calculated from the G-code in advance, given these values.

    For example, if we knew about it, we could take perfect account of those rounding off curves at the corners in the CAM software to make sure that they didn’t gouge.

    If the spec made clear that a feedrate setting on one block was linearly interpolated into the next block, this whole trapezium planning could be abolished and calculated in advance to respect the maximum acceleration. We could ensure that such changes occurred away from the part to avoid marks. We could choose to keep the feed down along a straight section of a complex contour where most of it is corners to maintain consistency. And so on.

    Alternatively, they may be controlling the acceleration in a proper feedback loop where the power-voltage to the motors is used to limit the motion at runtime. That is, the controller slows down the rate at which it commands the progresses along each millimetre of the toolpath when the servos start drawing above a certain voltage. Then it will respond naturally to the amount of weight and cutting force on the bed. Which would mean you could get away with lighter and cheaper motors because they do not need to be overengineered to provide good performance against the pre-coded motions.

    Either the industrial machines are doing one or the other. I intend to find out.

  • 6. Julian replies at 4th January 2016, 7:52 pm :


    Great! now another website I’ve got to spend all my time reading. Cnccookbook. Reminded me that I forgot lunch.

    Are the feeds and speeds calculations predominantly derived theoretically from the geometry? Is there any direct way of verifying them at the time?

    It just feels like this way of doing it strictly by the numbers must be partly out of date in this age.

    For example, in photography no one needs to go through all that hassle with apertures and f-stops any more. Granted, it had to be that way when the results were hidden within the black box of a film camera and it was impossible to detect the actual exposures on the light-sensitive chemicals until after developing them. But now with digital cameras the embedded computer simply reads the light exposures on the individual pixels and adjusts the shutter accordingly. It may not actually refer to a exposure table.

    Today I am almost certain I could use a MEMS sensor and high speed microcontroller to detect the force of every cutter tooth impact. There’s no reason this shouldn’t be steering these two parameters millisecond by millisecond as it progresses along the tool path. You’d expect some research department of these multibillion dollar machine tool manufactures to be pioneering this sort of tech.

    But that’s all for later. What I do need to do is wire the ER16 spindle[1] into the computer so I can see how much strain it is under, because it keeps struggling and then stalling at these ridiculously low spindle speeds and high feedrates recommended by the calculations. I had no idea it would be like this.


Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>