CNC milling with open source software(opensource.com)
opensource.com
CNC milling with open source software
https://opensource.com/article/19/1/cnc-milling-open-source-software
132 comments
If you're interested in Open-Source CNC you should check out two of my Open-Source projects. https://camotics.org/ a CNC simulator and https://buildbotics.com/ a CNC controller. I'm somewhat surprised neither of these were mentioned.
Do any of them support the arc or spline gcode? I noticed that most of the 3d printers do not, even though they are essentially 4-axis CNCs.
G3 and G4 arcs are supported but not splines. It would be easy to add spline support but there is very little demand for them. Since I released CAMotics in 2011 no one has asked for spline support.
3d printers typically don't care about arcs or splines since they only use STL files which do not have "real" curves.
Some firmwares support arcs (smoothieware, which is based on GRBL) but it still breaks the arcs down to segments.
Some firmwares support arcs (smoothieware, which is based on GRBL) but it still breaks the arcs down to segments.
>> 3d printers typically don't care about arcs or splines since they only use STL files which do not have "real" curves.
I would have thought the printer would support arcs even if the slicer doesn't. There is work going on to support arcs in slic3r (automatic detection of arcs) but it will be irrelevant for printers that don't support it. It's would also be possible for a slicer to import step files and find such surfaces. One can also approximate other curves with fewer gcodes if they use arcs vs lines - splines even fewer.
I would have thought the printer would support arcs even if the slicer doesn't. There is work going on to support arcs in slic3r (automatic detection of arcs) but it will be irrelevant for printers that don't support it. It's would also be possible for a slicer to import step files and find such surfaces. One can also approximate other curves with fewer gcodes if they use arcs vs lines - splines even fewer.
Some of the firmware versions do have G2/G3 in them but not all. http://smoothieware.org/supported-g-codes
I assume most of the modern ones do but some of the older 3d printing firmware use a very butchered version of the gcode "standard" which eliminate or rename many of the unused codes.
I assume most of the modern ones do but some of the older 3d printing firmware use a very butchered version of the gcode "standard" which eliminate or rename many of the unused codes.
I just flashed my Ender 3 using the latest Marlin version and I deactivated ARC support manually on it to save space. Considering how pretty much all 3D printers use a Marlin firmware, seems like ARC is supported pretty much everywhere.
Is there any reason why CNC machines aren't directly controlled by CAM software, beyond it always having been done that way?
I'd think it would be useful to integrate the two, instead of the CAM software just firing-and-forgetting toolpaths.
I'd think it would be useful to integrate the two, instead of the CAM software just firing-and-forgetting toolpaths.
(I have built and worked on a lot of CNC mills, routers, etc)
In some cases, it is.
There are integrated CAM + Machines depending on industry and price point. (see woodwop, etc, which are the interface to the machine)
The motion planning aspects can be taken care of (despite other comments), beckhoff, for example, does real time plc on windows machines by isolating cpus away from windows. i have no problem using it as a plc. They also support CNC control.
Outside of software like that, it's usually being taken care of by an FPGA card and that's a pain in the butt. Assume you can solve this.
You still have the next problem: Actually driving the machine.
First, the low level
Most of the servos in these machines are using pulse train inputs of some sort. That's what the FPGA cards are doing, generating the pulse outputs, etc.
It's only in the past 5 years that things like "drive my servo over ethercat instead" became viable.
They use simple relays, etc to control safety/limit switches/you name it.
Now i could use an ethernet based field-io. So i'd say they are actually now there (in the past 5 years) for the low level. I can run all my field io/spindles/servos off ethercat now, for example. I do, in fact, outside of servos (my cnc software can't drive them over ethercat yet)!
5 years ago i couldn't do this.
Okay, so that's one level up. Now i can at least drive it from the CAM software in some standardized way if i knew what was what. Which is your next problem - knowing what anything does. Which io's are the limit switches. How do you home the machine or execute a tool change? How do i turn on the vacuum? Which drives go with what axes?
There is no standardized way of describing this, such that a piece of CAM software could actually do anything.
We'll get there, mind you, but it'll be a while.
In some cases, it is.
There are integrated CAM + Machines depending on industry and price point. (see woodwop, etc, which are the interface to the machine)
The motion planning aspects can be taken care of (despite other comments), beckhoff, for example, does real time plc on windows machines by isolating cpus away from windows. i have no problem using it as a plc. They also support CNC control.
Outside of software like that, it's usually being taken care of by an FPGA card and that's a pain in the butt. Assume you can solve this.
You still have the next problem: Actually driving the machine.
First, the low level
Most of the servos in these machines are using pulse train inputs of some sort. That's what the FPGA cards are doing, generating the pulse outputs, etc.
It's only in the past 5 years that things like "drive my servo over ethercat instead" became viable.
They use simple relays, etc to control safety/limit switches/you name it.
Now i could use an ethernet based field-io. So i'd say they are actually now there (in the past 5 years) for the low level. I can run all my field io/spindles/servos off ethercat now, for example. I do, in fact, outside of servos (my cnc software can't drive them over ethercat yet)!
5 years ago i couldn't do this.
Okay, so that's one level up. Now i can at least drive it from the CAM software in some standardized way if i knew what was what. Which is your next problem - knowing what anything does. Which io's are the limit switches. How do you home the machine or execute a tool change? How do i turn on the vacuum? Which drives go with what axes?
There is no standardized way of describing this, such that a piece of CAM software could actually do anything.
We'll get there, mind you, but it'll be a while.
Low-level control your machine from your CAM workstation in the office building will never make much sense (where the CAM software directly talks to servos).
I would prefer my (probably expensive) machine to kind of "know" what it's physical limits are and guarantee that executed commands adhere to them.
I would prefer my (probably expensive) machine to kind of "know" what it's physical limits are and guarantee that executed commands adhere to them.
It depends on what you are talking about here.
CNC is used for a lot.
The assumption that there is a cam workstation, and that it's in an office building, is certainly not one i would make. I wouldn't also say "will never make much sense".
You seem to have some particular set of users in mind for which you believe it wouldn't make sense. Okay - i'm not sure that changes that there are plenty of sets of users for which it will?
I even gave you examples of high end wood machines that have CAM directly integrated. There are many.
(They can also be programmed offline, but)
As for "knowing" the physical limits.
That's not actually possible since it there is no way to self-configure it even if everything did talk to each other. They don't know their own physical orientations (and it would be very expensive/hard to do that, and you'd still be guessing in the end)
Most of the non-safety/accessory programming is essentially explaining enough of the physical orientation and placement of things to the motion control that it can do something.
The assumption that there is a cam workstation, and that it's in an office building, is certainly not one i would make. I wouldn't also say "will never make much sense".
You seem to have some particular set of users in mind for which you believe it wouldn't make sense. Okay - i'm not sure that changes that there are plenty of sets of users for which it will?
I even gave you examples of high end wood machines that have CAM directly integrated. There are many.
(They can also be programmed offline, but)
As for "knowing" the physical limits.
That's not actually possible since it there is no way to self-configure it even if everything did talk to each other. They don't know their own physical orientations (and it would be very expensive/hard to do that, and you'd still be guessing in the end)
Most of the non-safety/accessory programming is essentially explaining enough of the physical orientation and placement of things to the motion control that it can do something.
English is not my first language, so forgive me if I'm a bit ambiguous, it's not the intention.
CAM workstation (running some "generic" CAM package with machine specific configuration) in some office building was the precondition, in that case it will never make much sense to control a machine's servos from that workstation, in my opinion.
Integrating the CAM within the machine itself is something else, and yes, stuff like that existed for very long time, but that is something completely different IMHO.
The machine controller "knows" the physical limits because somebody configured it (and "locked" it). It would be hard to guarantee the integrity of this configuration if you put it on an arbitrary workstation to run CAM and machine control.
CAM workstation (running some "generic" CAM package with machine specific configuration) in some office building was the precondition, in that case it will never make much sense to control a machine's servos from that workstation, in my opinion.
Integrating the CAM within the machine itself is something else, and yes, stuff like that existed for very long time, but that is something completely different IMHO.
The machine controller "knows" the physical limits because somebody configured it (and "locked" it). It would be hard to guarantee the integrity of this configuration if you put it on an arbitrary workstation to run CAM and machine control.
There will always be some sort of interface between CAM and other design tools and the physical apparatus to execute assembly. I think we're all just being pedantic in this thread; is it likely you're going to hook your workstation directly to the multi-axis mill? No. Is it more likely we're going to have some sort of queue and bus that'll allow you to send more complex instruction sets to assembly systems? I think so (based on my interaction with a firm who is doing this for high precision additive manufacturing). What that looks like is going to depend on the complexity of your shop floor, and manufacturing demands.
> They don't know their own physical orientations...
Wait, so even the really high-end gear in high-end names like DMG Mori don't use something like millimeter radar, ultrasound or machine vision to confirm that real-world orientations at least correspond to within a few orders magnitude accuracy of what is expected? If so, then mad props to you machining guys working with such expensive kit without continuous closed loop monitoring conditions; you re-e-a-a-ally like to live on the wild side.
Wait, so even the really high-end gear in high-end names like DMG Mori don't use something like millimeter radar, ultrasound or machine vision to confirm that real-world orientations at least correspond to within a few orders magnitude accuracy of what is expected? If so, then mad props to you machining guys working with such expensive kit without continuous closed loop monitoring conditions; you re-e-a-a-ally like to live on the wild side.
CAM can take a lot of time and need considerable computing resources. Not that much of issue today, but still, why do the same computations over and over again? Also, you will want to inspect the toolpaths before running them on real hardware.
Yeah, you'd still definitely want to look at the toolpaths. As far as recalculating everything, it could still calculate most of it ahead of time.
What I'm thinking of is something like a CAM workspace in FreeCAD. That is, something like would let you take your model, generate and inspect a toolpath (or flip through possible toolpaths), and produce a part. The CAM software would get feedback from the controller, so it could follow what was going on.
It might also be possible to make adjustments, or pause the run, based on sensors. For instance, if you could detect chatter, you could slow down the feed rate; if you could detect a broken tool, you could pause the run and ping the operator.
What I'm thinking of is something like a CAM workspace in FreeCAD. That is, something like would let you take your model, generate and inspect a toolpath (or flip through possible toolpaths), and produce a part. The CAM software would get feedback from the controller, so it could follow what was going on.
It might also be possible to make adjustments, or pause the run, based on sensors. For instance, if you could detect chatter, you could slow down the feed rate; if you could detect a broken tool, you could pause the run and ping the operator.
It should not be that hard to export current axis positions and get it into FreeCAD. Look at machinekit, they have remote control and toolpath display. Pause/run/start, override of feed and spindle speeds also is easy.
Detecting chatter is not that easy. Slowing down may be wrong, sometimes it is better to speed up.
Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project.
Detecting chatter is not that easy. Slowing down may be wrong, sometimes it is better to speed up.
Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project.
"Detecting chatter is not that easy. Slowing down may be wrong, sometimes it is better to speed up."
Errr? Detecting chatter is easy, and in fact, the latest spindles output the current tool vibration rate over your choice of fieldbus. That's fairly basic, much more advanced things are done.
"Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project."
Why? Toolpaths are already adjusted on the fly. Integrating CAM does not make this particularly harder - any of these machines have hardware motion planning anyway. Adding another FPGA or two to accelerate 5 axis movement calculation would not materially change their cost.
Errr? Detecting chatter is easy, and in fact, the latest spindles output the current tool vibration rate over your choice of fieldbus. That's fairly basic, much more advanced things are done.
"Doing on-the-fly adjustments of toolpaths in CAM integrated into a machine control would be a major research project."
Why? Toolpaths are already adjusted on the fly. Integrating CAM does not make this particularly harder - any of these machines have hardware motion planning anyway. Adding another FPGA or two to accelerate 5 axis movement calculation would not materially change their cost.
The upcoming version of CAMotics talks directly to the Buildbotics CNC controller. The path planning code is shared. So there's no reason why the CAM software and controller cannot be tightly integrated.
The gcode emitted by CAM software is quite literally the assembly code of CNC machines.
Your question is somehow similar to "why can't the C code directly control the CPU"?
Your question is somehow similar to "why can't the C code directly control the CPU"?
no, it's mostly historic, I did a project on that topic in the past: https://github.com/nraynaud/webgcode
Wild assed guesses:
Damage/safety issues: operating the milling machines incorrectly, or in an untimely manner.
Related to latter point: lack of hard real-time processing in the upstream software?
Damage/safety issues: operating the milling machines incorrectly, or in an untimely manner.
Related to latter point: lack of hard real-time processing in the upstream software?
1. You can do SIL-* in software.
2. See, e.g., beckhoff :)
(Both are these are solvable, it's interfacing with the machine in any standardized way that is not)
(Both are these are solvable, it's interfacing with the machine in any standardized way that is not)
Will you be adding servo support in the future?
Steppers are great, but anything big needs a servo, as the steppers get to expensive and too slow very quickly.
Steppers are great, but anything big needs a servo, as the steppers get to expensive and too slow very quickly.
No servo support yet but we can drive NEMA 23s and 34s at up to 4k RPM.
Edit: We are adding step and direction outputs which could be used to control an external servo driver. You can actual access these outputs now of you are alright with soldering some headers on to the main board.
In the future, we do plan to make a servo version of the Buildbotics CNC controller.
Edit: We are adding step and direction outputs which could be used to control an external servo driver. You can actual access these outputs now of you are alright with soldering some headers on to the main board.
In the future, we do plan to make a servo version of the Buildbotics CNC controller.
FYI there are hybrid steppers now, which helps with some of the traditional stepper drawbacks. See e.g.
https://youtu.be/NARodU-vVWs
https://youtu.be/NARodU-vVWs
can you point to some continuous rotation servos that would replace steppers? I haven't been able to find any that are affordable.
If you want small servos, just use steppers with drivers like TMC2130.
Anything bigger, many people seem to like ClearPath servos. Price to performance seem to be pretty good.
Anything bigger, many people seem to like ClearPath servos. Price to performance seem to be pretty good.
I believe he means servos as "high-speed DC brushless motors with feedback" not the low cost gearmotor servos used in R/C models.
It is about $1000 an axis for 1/2 hp AC servo + amplifier from China. But worth every penny. Some productive work can be done with bigger step motors. But setups with little ones are soon abandoned.
but those aren't affordable! also you can buy steppers with feedback in NEMA34+ form factor for not too much. I use them in my machines.
Camotics is wonderful, thanks! I did have some problems testing some super complicated toolpaths (millions of lines long) though...
Cool -- just took a quick look, downloaded and I'll be trying it out soon -- thanks!
CNC is programming "for keeps".
Any tiny little error in your gcode has a chance to crash the machine. Unlike a computer crash, a CNC crash results in broken metal flying across the room and anywhere from $5- to $5000 in damage. I programmed for a heavy machine shop for a year before I gave up and went back to making websites.
Hobby CNC is fun though, it is amazing what you can make out of wood when you can shape it with sub-millimeter precision. Also hobby machines are not strong enough to cause serious damage when you crash.
Any tiny little error in your gcode has a chance to crash the machine. Unlike a computer crash, a CNC crash results in broken metal flying across the room and anywhere from $5- to $5000 in damage. I programmed for a heavy machine shop for a year before I gave up and went back to making websites.
Hobby CNC is fun though, it is amazing what you can make out of wood when you can shape it with sub-millimeter precision. Also hobby machines are not strong enough to cause serious damage when you crash.
Yes. This article is about very low end CNC, just 2D routing.
Using a Dremel tool as a CNC router never works very well. The motor isn't constant speed, slows way down under load, and can overheat. The bearings can't take side loads for long, either. It's been tried. A Bosch router from Home Depot works much better. Those can cut wood all day. You can take off the handles, leaving a motor cylinder that can easily be clamped. Also, enclose the electronics in something that will keep the dust out. If the stepper motors are not dust-tight, they also need dust protection.
You need dust removal. Any CNC router doing useful work generates sawdust in huge quantities, much more dust than hand woodworking. Absolute minimum is a Shop-Vac sucking dust from the cutting area.
Trying to make a machine tool from low-end 3D printer parts does not work very well. There are some far better open source CNC wood router designs. The Maslow project [1] is especially clever and very useful, since it can make furniture-sized wood parts on a low-cost machine.
[1] https://www.maslowcnc.com/
Using a Dremel tool as a CNC router never works very well. The motor isn't constant speed, slows way down under load, and can overheat. The bearings can't take side loads for long, either. It's been tried. A Bosch router from Home Depot works much better. Those can cut wood all day. You can take off the handles, leaving a motor cylinder that can easily be clamped. Also, enclose the electronics in something that will keep the dust out. If the stepper motors are not dust-tight, they also need dust protection.
You need dust removal. Any CNC router doing useful work generates sawdust in huge quantities, much more dust than hand woodworking. Absolute minimum is a Shop-Vac sucking dust from the cutting area.
Trying to make a machine tool from low-end 3D printer parts does not work very well. There are some far better open source CNC wood router designs. The Maslow project [1] is especially clever and very useful, since it can make furniture-sized wood parts on a low-cost machine.
[1] https://www.maslowcnc.com/
I have to repeat the points in this comment. I've worked extensively with low-cost CNCs, and they can't really do anything more than light engraving of aluminum and slow cutting of wood. There are some straightforward physical reasons for this (there is no cheap and fast replacement for mass and torque).
You’re absolutely right. If you’ve been around industrial grade equipment, it’s painful to watch hobbyists fiddle with equipment that is not very productive, and soon abandoned.
You don't even need a commercial product like a ShopBot.
There are some good low-cost DIY projects and kits using Bosch palm routers. Repurposed 3D printer parts are far too wimpy for this.
There are two types of dremels in the world, those about to overheat and those that are burned out.
A poorly programmed CNC machine can drill a gaping hole in itself, and into the table that it stands on. Don't ask me how I know.
If there was no table, it would be the ground, and yes, it would. Not many things can stand in the way of a spindle hell-bent on chopping chips off a block of titanium.
It's a very fun thing to play with, though. Probably the most high-stakes programming most of us are ever going to get.
If there was no table, it would be the ground, and yes, it would. Not many things can stand in the way of a spindle hell-bent on chopping chips off a block of titanium.
It's a very fun thing to play with, though. Probably the most high-stakes programming most of us are ever going to get.
In other words, don't mix up your G0 , G1 , G90 , and G91 .
Much sadness will ensue.
Much sadness will ensue.
God, I hate how G commands are sticky in Mach 3. Much sadness indeed.
Can the CNC machine computer not simulate the program and see if it violates some safety rules like cutting into the table or removing too much material at a time?
It's not that easy. You need accurate models of your machine, the tools and the stock material. Your simulation has to be linked to the real machine movements and be ahead of time so you can estop the machine before the crash happens.
But that still doesn't help in case of insufficient workholding or breaking tools.
But that still doesn't help in case of insufficient workholding or breaking tools.
It seems like the machine itself could implement some safety checks, like if a motor is commanded to go outside of its range of motion you trigger a stop with an error code and let the operator sort it out.
Or go even more oldschool and have physical safeties on the machine that trip if your cutting tool attempts to exit the work area. I mean these aren't cheap machines, it seems like they could be engineered to be just a bit safer and error resistant.
Or go even more oldschool and have physical safeties on the machine that trip if your cutting tool attempts to exit the work area. I mean these aren't cheap machines, it seems like they could be engineered to be just a bit safer and error resistant.
I'm not a CNC machine operator, but I have written a lot of code for motion control systems. Typically, the machine can protect itself in that it knows where the limits are and how not to exceed them.
The problem usually comes up by crashing into something that is inside its known workspace. e.g., cutting into a vise instead of the object that's held in the vise, or an incorrect offset causing a crash into the table. The machine may know that it can only travel up or down by 12.500 inches, but it has to hold cutting tools that may be of unknown length and that can cause it to hit things (like its own table).
The problem usually comes up by crashing into something that is inside its known workspace. e.g., cutting into a vise instead of the object that's held in the vise, or an incorrect offset causing a crash into the table. The machine may know that it can only travel up or down by 12.500 inches, but it has to hold cutting tools that may be of unknown length and that can cause it to hit things (like its own table).
The machines do some sanity checking. Most of the issues come from the machine being improperly informed about what is on the table(height or shape) or the length of the tool in the spindle. The tool length can be tested if you have the hardware, but it's more difficult to scan the whole table for stuff that might get in the way.
If an axe could detect your thumb was in the way, it would no longer be useful.
There's a balance. Sometimes it really is up to the operator to maintain safety. Sometimes the machine can handle it. IMHO, other than reliably finding zero, everything else is up the the operator. The tool doesn't REALLY know how big it is or how fast it's going (just what it was told), and even if it did know, some operator would screw it up assuming that the tool was smart enough to adjust itself.
There's a balance. Sometimes it really is up to the operator to maintain safety. Sometimes the machine can handle it. IMHO, other than reliably finding zero, everything else is up the the operator. The tool doesn't REALLY know how big it is or how fast it's going (just what it was told), and even if it did know, some operator would screw it up assuming that the tool was smart enough to adjust itself.
gotta disagree. I don't know anybody who works in a machine shop and doesn't want sawstop enabled, unless they need to disable it for a specific cut (wet wood).
Real CNC machines have limit switches, they monitor the load on the axis and spindle servos etc etc. But that doesn't prevent running your cutter into a fixture at positioning speed and ruining the spindle bearings.
My tin arse Cnc mill I made has stop switches. Probably the cheapest part of the whole thing and saves it grinding itself when you balls the code up :D
Do those stop switches prevent crashing the mill into a fixture? If so, how?
Do you manually monitor the entire job cycle?
Do you manually monitor the entire job cycle?
High end CNC controls have chuck barrier software built in that makes this less likely. It needs to be skillfully set up. High end shops may also have good 3D rendering software that can be used to prove out toolpaths. The programmer will model his machines and fixtures accurately so he can then prevent crashes. Average CNC controls at least have line output graphics that prevent non-subtle mistakes. Finally, the operator will run the first part peering into the machine, with non-cutting rapid traverse moves artificially slowed down, and with her finger poised over the feed hold button.
"For keeps" is right!
Years ago I was helping a friend model a cam at the heart of a large piece of metals processing equipment for these guys: https://www.butechbliss.com
It was _almost_ right, but had a negative curvature on one surface. The effect was to lift a multi-ton piece of machinery off the floor – which it was bolted to.
My understanding is that the cam is now used as a coffee table!
Years ago I was helping a friend model a cam at the heart of a large piece of metals processing equipment for these guys: https://www.butechbliss.com
It was _almost_ right, but had a negative curvature on one surface. The effect was to lift a multi-ton piece of machinery off the floor – which it was bolted to.
My understanding is that the cam is now used as a coffee table!
Spindle crashes are terrifying. I've had a few. I've destroyed tools and pieces. Cost thousands of dollars in damage from a single misplaced tool path or lead in/out.
There's also this very transitive nature to the programs. Unless you make a whole bunch of the same pieces your programs tend to be one time use. 99% of the things we make in our shop are fully custom meaning brand new programs for every single table.
There's also this very transitive nature to the programs. Unless you make a whole bunch of the same pieces your programs tend to be one time use. 99% of the things we make in our shop are fully custom meaning brand new programs for every single table.
[deleted]
I program non-ferrous CNCs. Someone-who-wasn't-me crashed the head (router motor). $35k. Instantly. Breaking $160 bits is trivially easy.
>I programmed for a heavy machine shop for a year before I gave up and went back to making websites.
Yeah, very few people seem to be able to transition from "ship it now, fix it later" tech to programming for industrial purposes where you can't test everything without risking physical hardware. The other way around seems to be a much easier transition.
Yeah, very few people seem to be able to transition from "ship it now, fix it later" tech to programming for industrial purposes where you can't test everything without risking physical hardware. The other way around seems to be a much easier transition.
>>Any tiny little error in your gcode has a chance to crash the machine.
I would assume that an emulator for the machine exists that allows you to test your program before trying it out on the real thing. Was that not the case?
I would assume that an emulator for the machine exists that allows you to test your program before trying it out on the real thing. Was that not the case?
Good CAD/CAM software will detect obvious errors in the toolpath, but there are things that require common sense. A large proportion of machine crashes are caused by a discrepancy between the computer model and the real state of the machine, which the software is obviously unable to detect or prevent. CNC machines generally have no sensing capabilities; they rely on the operator to provide accurate measurements on tool height and work positioning. A transposed digit or a value entered in the wrong field can easily cause an ugly crash.
Workholding is a common issue - a 3D model just floats in abstract space, but a real part needs to be securely held in place. It's quite easy to inadvertently crash a tool or spindle into a clamp or vise, or to apply cutting forces that exceed the clamping force and throw the part.
https://www.youtube.com/watch?v=PsFNeiAu04M
Workholding is a common issue - a 3D model just floats in abstract space, but a real part needs to be securely held in place. It's quite easy to inadvertently crash a tool or spindle into a clamp or vise, or to apply cutting forces that exceed the clamping force and throw the part.
https://www.youtube.com/watch?v=PsFNeiAu04M
Is there no way to test? Or there is, just not everything?
The best shops use simulation tools, but you need the 3D models / configurations of everything to make them work, and then the machinist still needs to load everything correctly. It's very easy to make a mistake.
Check out a simulator here: https://www.ncsimul.com/
Check out a simulator here: https://www.ncsimul.com/
There are machines that are "self-aware" in the sense that they run a simulation parallel to the NC control, slightly advanded in time, to catch catastrophic crashes and ESTOP the machine. Cutting into the machine bed can be _very_ expensive.
Which machines are you referring to?
How aware? Do they have any vision? Can they "see" or otherwise "know" about the cutters / workholding?
How aware? Do they have any vision? Can they "see" or otherwise "know" about the cutters / workholding?
I know of WFL millturns with crashguard.
AFAIK the crash guard is a separate component that relies on 3d models of the machine and the tools, it doesn't see anything.
If you workholding is weak and a piece comes loose the crash guard probably won't make a difference.
AFAIK the crash guard is a separate component that relies on 3d models of the machine and the tools, it doesn't see anything.
If you workholding is weak and a piece comes loose the crash guard probably won't make a difference.
>machinist still needs to load everything correctly. It's very easy to make a mistake.
Tool configuration is kinda-sorta solved with ISO 13399, this is being supported in more and more CAM systems and tool vendors, but as you say it is very easy to make a mistake.
Assuming the mistakes are happening when the tool data is reduced from the comprehensive format that ISO 13399 supports to the barebones and simple TxDxHx format that is loaded on CNC machine. Would be nice if machine tools supported a comprehensive format directly.
Tool configuration is kinda-sorta solved with ISO 13399, this is being supported in more and more CAM systems and tool vendors, but as you say it is very easy to make a mistake.
Assuming the mistakes are happening when the tool data is reduced from the comprehensive format that ISO 13399 supports to the barebones and simple TxDxHx format that is loaded on CNC machine. Would be nice if machine tools supported a comprehensive format directly.
Not to mention workholding, etc. that might be off.
Tooling data in a G-Code data structure bootstrapped with G65 and M98 would support fixture models.
Certainly a chicken and egg problem though, my ideal future would have CAD files generated from single source of truth CNC files:)
Certainly a chicken and egg problem though, my ideal future would have CAD files generated from single source of truth CNC files:)
We use a very simple method: overlay the position of the head/arm
of the machine on top of the DXF file of the table.
If the supports/bars are in the overlay, the operator DOES NOT run that part and takes it back to design.
If the supports/bars are in the overlay, the operator DOES NOT run that part and takes it back to design.
There's a lot that can go wrong, and it's too much work & tech integration for most shops to make the investment.
Even if you have the 3D models for everything involved: tooling, tool holders, stock material, fixtures, CNC machine, along with the instructions for the movement of all of it, there are still many opportunities for both configuration errors and runtime crashes.
For instance, CAM tools usually simulation axis movements only, before they've been converted to gcode/NC. If there's a bug in your post-processor that generates gcode or if it doesn't perfectly match your machine configuration, you're going to crash.
Even if you use a simulation tool like Vericut or NCSIMUL, which both simulate using the actual gcode, the physical machine settings may be out of sync, or there could be a wrong piece of stock material loaded or some foreign object (a wrench) that causes a crash.
Probing routines and careful selection of Work Coordinate Systems can help verify/eliminate some of these unknowns at runtime, but it's still no guarantee that the part will come out right.
Hardware is hard!
Even if you have the 3D models for everything involved: tooling, tool holders, stock material, fixtures, CNC machine, along with the instructions for the movement of all of it, there are still many opportunities for both configuration errors and runtime crashes.
For instance, CAM tools usually simulation axis movements only, before they've been converted to gcode/NC. If there's a bug in your post-processor that generates gcode or if it doesn't perfectly match your machine configuration, you're going to crash.
Even if you use a simulation tool like Vericut or NCSIMUL, which both simulate using the actual gcode, the physical machine settings may be out of sync, or there could be a wrong piece of stock material loaded or some foreign object (a wrench) that causes a crash.
Probing routines and careful selection of Work Coordinate Systems can help verify/eliminate some of these unknowns at runtime, but it's still no guarantee that the part will come out right.
Hardware is hard!
Most decent CAM software has at least some simulation routines, which is helpful, but definitely not definitive. There can often be errors such as defaults that are bad in some situation that create a lead-in/out that tries to clear the tool, but actually digs the full length of it into the solid material, and this might not be noticed in the simulation.
I've also frequently mocked up styrofoam stock material and run the entire toolpath through that, which can be very helpful, but again, not definitive.
Ultimately, you need to just be really careful about the toolpath creation, and watch the first run like a hawk, which can take hours. Pausing and starting each new segment at a fraction of normal speed can help also.
The cool thing is that once you've run the toolpath a few times and can trust it, you can almost start it and ignore it while the part gets made (note that the operative word is almost).
Even with the difficulties, when you have a good machine and some skills (and patience), it is quite rewarding what you can make!
I've also frequently mocked up styrofoam stock material and run the entire toolpath through that, which can be very helpful, but again, not definitive.
Ultimately, you need to just be really careful about the toolpath creation, and watch the first run like a hawk, which can take hours. Pausing and starting each new segment at a fraction of normal speed can help also.
The cool thing is that once you've run the toolpath a few times and can trust it, you can almost start it and ignore it while the part gets made (note that the operative word is almost).
Even with the difficulties, when you have a good machine and some skills (and patience), it is quite rewarding what you can make!
Some CNC machines, like the Bantam Tools "Othermill", have software that does a "test" and will tell you if you'll crash into the board, and can recommend drill bit sizes. I'd highly recommend this machine btw, excellent support and I've been very happy with the results for both wood and PCBs.
You can put all your workholding devices (vice, clamps, etc.) and toolholder into your CAM software and it will find some crashes during simulations.
Most CAM will do good simulations.
I usually run a new program without an actual cutter in the spindle. Then I run it with the cutter but 2-3" above the actual material to be cut.
Many people will do trial runs on machinable wax.
Most CAM will do good simulations.
I usually run a new program without an actual cutter in the spindle. Then I run it with the cutter but 2-3" above the actual material to be cut.
Many people will do trial runs on machinable wax.
I work with the smoothieware project (hardware QA). It is an opensource motion control firmware and openhardware control board which works with 3d printers, lasers, mills, etc. Initially based on GRBL and runs on ARM (LPC1769).
The openhardware scene has advanced quite nicely in the last 5 years. There are many very nice projects out there to build from which are largely able to be built at home with parts which can be made locally and/or purchased online. Openbuilds is a good place to start if you are interested.
I always try to remind people...whether it is 3d printers, mills, lasers...the knowledge gain from building/breaking/rebuilding your machine far outweighs the small gain you get from simply operating one. I have never printed an object as interesting to me as it was to create and design an entire working machine from scratch.
If anyone is interested in openhardware projects I recommend checking out reprap.org , smoothieware.org , openbuilds.com as well as several other projects which I am sure you will stumble upon through research on those sites.
There are many opensource CAD/CAM software packages out there which allow you to pick and choose what you like. I personally use Fusion360 for most of my CAD/CAM stuff (I know...not Opensource) and for 3d printing my personal favorite is Slic3r.
The openhardware scene has advanced quite nicely in the last 5 years. There are many very nice projects out there to build from which are largely able to be built at home with parts which can be made locally and/or purchased online. Openbuilds is a good place to start if you are interested.
I always try to remind people...whether it is 3d printers, mills, lasers...the knowledge gain from building/breaking/rebuilding your machine far outweighs the small gain you get from simply operating one. I have never printed an object as interesting to me as it was to create and design an entire working machine from scratch.
If anyone is interested in openhardware projects I recommend checking out reprap.org , smoothieware.org , openbuilds.com as well as several other projects which I am sure you will stumble upon through research on those sites.
There are many opensource CAD/CAM software packages out there which allow you to pick and choose what you like. I personally use Fusion360 for most of my CAD/CAM stuff (I know...not Opensource) and for 3d printing my personal favorite is Slic3r.
I re-implemented (most of) TPLang (mentioned above) in pure JS , and called it openjscam [1]
And am working on open source software for CAM (as a hobby), just 2.5D gcode generators, using maker.js and openjscam [2].
And made opencamlib compile on Mac and Windows (and added basic Node.JS bindings) [3]
I am hoping more people will work on open source g-code generators so we have better alternatives to Fusion 360 / Solidworks for free
[1] http://github.com/makercam/openjscam [2] http://github.com/makercam [3] https://github.com/aewallin/opencamlib
I am hoping more people will work on open source g-code generators so we have better alternatives to Fusion 360 / Solidworks for free
[1] http://github.com/makercam/openjscam [2] http://github.com/makercam [3] https://github.com/aewallin/opencamlib
For controlling your machine there is LinuxCNC (formerly Enhanced Machine Controller, created at NIST) http://www.linuxcnc.org and the fork MachineKit http://www.machinekit.io/
Also, latest FreeCAD has a CAM module ("Path workbench") that has come a long way and really is useful.
Also, latest FreeCAD has a CAM module ("Path workbench") that has come a long way and really is useful.
G-code is the most hilariously bad language. Keywords are G + a number, e.g. G01, with wildly different effects, varying arg lists and no standard. E.g. G01 move to position, G20 set the machine units to inches. Its often stateful.
Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see
https://en.m.wikipedia.org/wiki/G-code
Obviously its coz its old and works, but i chuckle everytime i have to look up the codes at how comically awful it is compared to anything else i see
https://en.m.wikipedia.org/wiki/G-code
The g-code variant my machines use contains most of the control structures of modern programming languages. It has variables, comparisons, loops, subroutines, the codes are all fairly straight forward and honestly a lot of g-code is produced automatically with CAM software rather than being written manually these days.
It's a simple language, you don't have to memorize the codes and you end up memorizing the few you use most often anyway.
Honestly the actual math and figuring out the toolpaths for your machine ia far harder than writing the g-code for it.
It's a simple language, you don't have to memorize the codes and you end up memorizing the few you use most often anyway.
Honestly the actual math and figuring out the toolpaths for your machine ia far harder than writing the g-code for it.
Have you been able to arrive at any clear repeatable structure in your macro programming, or is it just ad-hoc make it fit for this job and this machine?
Asking, because I am trying to level up cnc programming to "normal" programming.
Asking, because I am trying to level up cnc programming to "normal" programming.
Not so much no. About the closest i come is reusing the same program for pieces that are identical. This rarely happens.
The cam software i use does come with a few handy baked in things. Stuff like automatically lowering the feedrate for corners under a certain radius or for setting up z-level ramps.
There's a couple i can think of being handy. Functions for automatically decreasing feedrates at certain axis loads or horsepowers would be nice.
I think it would come down to something more like a handy library of functions for little things like that rather than anything really repeatable. Even that would likely be specific to whatever machine you use though.
The cam software i use does come with a few handy baked in things. Stuff like automatically lowering the feedrate for corners under a certain radius or for setting up z-level ramps.
There's a couple i can think of being handy. Functions for automatically decreasing feedrates at certain axis loads or horsepowers would be nice.
I think it would come down to something more like a handy library of functions for little things like that rather than anything really repeatable. Even that would likely be specific to whatever machine you use though.
Check out https://TPLang.org/ for a JavaScript based Open-Source alternative to GCode. I'm the author.
Looks like more of a programming language than a list of commands like g-code. That's not a good design in my opinion. I mean do you expect CNC machines and CAD programs to embed JavaScript interpreters? Or does it export to g-code? In which case it isn't really an alternative.
Hey that’s really cool I’m going to have a play with this. Thanks
>G-code is the most hilariously bad language
Let's do a web site programming analogy(weak but relatable), because JS is now a mature programming language with advanced interpreters. This was not the case back when JS was used to make text dance and a few other useful ad-hoc solutions.
-Early web days with just html is like plain g-code spit out from cam systems.
-Early javascript is like macro options available on industrial cnc[1][2][3].
-Mid years javascript is where cnc macro program is heading, isolated shops doing some awesome things but no industry wide adoption of a coherent system.
-Late years javascript is where cnc macro programming needs to be if we want proper revision control and all the other benefits that normal programmers have afforded themselves.
Which brings us to real digital twins(monozygotic, not the fraternal state of the art), a single source of truth digital file should manifest as both a real world part on the shop floor and a virtual object in the top floor to be used by all the departments.
To close the analogy, like nodejs affords developing on the backend and the frontend with the same language.
[1] http://parts.haascnc.com/haasparts/en/USD/Performance-Upgrad...
[2] https://www.fanucamerica.com/fanuc-america-product-support/f...
[3] https://www.cncci.com/resources/tips/w%20custom%20macro.htm
Let's do a web site programming analogy(weak but relatable), because JS is now a mature programming language with advanced interpreters. This was not the case back when JS was used to make text dance and a few other useful ad-hoc solutions.
-Early web days with just html is like plain g-code spit out from cam systems.
-Early javascript is like macro options available on industrial cnc[1][2][3].
-Mid years javascript is where cnc macro program is heading, isolated shops doing some awesome things but no industry wide adoption of a coherent system.
-Late years javascript is where cnc macro programming needs to be if we want proper revision control and all the other benefits that normal programmers have afforded themselves.
Which brings us to real digital twins(monozygotic, not the fraternal state of the art), a single source of truth digital file should manifest as both a real world part on the shop floor and a virtual object in the top floor to be used by all the departments.
To close the analogy, like nodejs affords developing on the backend and the frontend with the same language.
[1] http://parts.haascnc.com/haasparts/en/USD/Performance-Upgrad...
[2] https://www.fanucamerica.com/fanuc-america-product-support/f...
[3] https://www.cncci.com/resources/tips/w%20custom%20macro.htm
What would a good G-Code variant look like? For all its flaws, it's pretty good at encoding the exact thing you want the CNC machine to do and while there certainly are different post-processors for different machines and in most cases they're not optional, it's also not like they're entirely different.
I think of G-code as ASM. For high-performance work you might write code differently for different (related) machines, but it's still a pretty OK compilation target.
I think of G-code as ASM. For high-performance work you might write code differently for different (related) machines, but it's still a pretty OK compilation target.
A good G-Code variant would roll up the un-rolled loops and separate the geometry data from the tool config data. This is what the view of a CAM IDE presents, G-Code source can be structured the same. If you change the semantics on some of the syntax you get lexically scoped blocks, macro-b subsystem which has existed for decades needs to be fully utilized for this to happen.
A fully implemented system would provide the CAM GUI engineer and the CNC CLI machinist to work on the same file, skipping post-processing entirely.
And, finally implement what was originally envisioned but not possible on even the most powerful mainframes of the late 50's: https://youtu.be/ob9NV8mmm20
A fully implemented system would provide the CAM GUI engineer and the CNC CLI machinist to work on the same file, skipping post-processing entirely.
And, finally implement what was originally envisioned but not possible on even the most powerful mainframes of the late 50's: https://youtu.be/ob9NV8mmm20
Eventually, something actuates a servo, and servos don’t understand iteration. Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)? If so, do you agree you’re just advocating for that layer to be part of the machine?
Speaking from user space that has G65 macro-b option, not machine tool builder (sudo) space.
>I think of G-code as ASM.
>Eventually, something actuates a servo, and servos don’t understand iteration.
I think of it more as an intermediate language. Interpreted on the CNC control and JIT compiled to whatever the RT system needs for servo control.
>Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)?
It does exist and a strict subset with enough primitives to bootstrap an application VM should continue to exist.
>If so, do you agree you’re just advocating for that layer to be part of the machine?
I am advocating for a DSL one layer up to be part of the CNC machine with support offline in say the JVM.
I want to answer this question, “how do we deploy MBE?” https://www.nist.gov/news-events/events/2019/04/model-based-...
The answer needs to be a single digital file that can render real parts and virtual parts. Why not?
>I think of G-code as ASM.
>Eventually, something actuates a servo, and servos don’t understand iteration.
I think of it more as an intermediate language. Interpreted on the CNC control and JIT compiled to whatever the RT system needs for servo control.
>Do you agree eventually something with g-codes level of detail must exist (even if it’s just unspecified internal commands)?
It does exist and a strict subset with enough primitives to bootstrap an application VM should continue to exist.
>If so, do you agree you’re just advocating for that layer to be part of the machine?
I am advocating for a DSL one layer up to be part of the CNC machine with support offline in say the JVM.
I want to answer this question, “how do we deploy MBE?” https://www.nist.gov/news-events/events/2019/04/model-based-...
The answer needs to be a single digital file that can render real parts and virtual parts. Why not?
It would look like something like this:
go_home
set_units mm
set_movements relative
activate_tool 0
move X 10
move Y 10
That's because the above would be highly wasteful on a slow serial link, like the ones gcode was made on and for.
That said, I bet vim syntax highlighting could get you most of what you want. Color code movement, configuration, values, maybe display the toolhead status and position at your current line in the status bar...
That said, I bet vim syntax highlighting could get you most of what you want. Color code movement, configuration, values, maybe display the toolhead status and position at your current line in the status bar...
Well, a gcode file is usually entirely composed of "move" operations. I'm adding one extra character on a 8 characters (at a minimum) line, for an increase of 12.5% at the worst case.
A CNC moves with speeds on the mm/s range. So does a 3D printer (unless you ask for larger movements, but those take less codes/s). They also have a precision on the 100's of µm, but let's push it down to 10's here so we overestimate things by an order of magnitude.
That means they'll need around 1000 codes/s, with a minimum of 64kbps on the 8 character case, or 72kbps with my codes. I don't think there is any serial interface chipset on the market that can't do 512kbps even on a 100's of meters long cable. Not to say that everything nowadays runs over USB anyway.
The gcodes are a leggacy that isn't needed anymore. And since both sides of the CNC link are composed of overpowered computers doing anything on software, the only reason it didn't change already is because nobody bothered to do something better. I'm not much bothered by them either so, I'm not jumping over it, but it is suboptimal.
A CNC moves with speeds on the mm/s range. So does a 3D printer (unless you ask for larger movements, but those take less codes/s). They also have a precision on the 100's of µm, but let's push it down to 10's here so we overestimate things by an order of magnitude.
That means they'll need around 1000 codes/s, with a minimum of 64kbps on the 8 character case, or 72kbps with my codes. I don't think there is any serial interface chipset on the market that can't do 512kbps even on a 100's of meters long cable. Not to say that everything nowadays runs over USB anyway.
The gcodes are a leggacy that isn't needed anymore. And since both sides of the CNC link are composed of overpowered computers doing anything on software, the only reason it didn't change already is because nobody bothered to do something better. I'm not much bothered by them either so, I'm not jumping over it, but it is suboptimal.
Not really, it cant do helical cuts.
What do you want out of helical cuts that G03s don’t give you?
At first glance, it looks like an assembly language. Does anything compile to it?
Yes, http://tplang.org compiles to GCode. Or rather, it produces GCode when executed.
> Does anything compile to it?
Compilers targeting G-code are called CAM software.
Compilers targeting G-code are called CAM software.
Even though I love 3d-printing, and designing/building machines, I would not build a small CNC like that from scratch. Since you get better machines for <200 USD that runs open source firmware (grbl) out of the box. Recently got one of them for PCB milling, a CNC 3018 Pro
I've been eyeballing the CNC 3018 Pro for a few weeks now. I would appropriate any input you have on the device. Pros/cons/alternatives I should look at. Anything!
If you've the budget for it, a Shapeoko3 is way more capable.
https://carbide3d.com/shapeoko/
:)
https://carbide3d.com/shapeoko/
:)
Please share your experience. This CNC 3018 Pro looks like a compelling option. I don't see many reviews on them that focus on open source tooling.
I got into CNC milling about 9 months ago. SVG to 2.5D problems are easy, and get you to a lot of cute solutions, its about as close to the work flow of 3D printers as you can get.
But the really interesting stuff is when you get to CAM. Multiple tool paths, genuine 3D cutting. Moving the work between paths etc. Its like going from juggling 3 balls (2.5d) to 5 balls (3D).
I haven't seen any competitive opensource CAM products, and its the main reason I continue to use Fusion 360 instead of OpenSCAD or SVG for my designs.
But the really interesting stuff is when you get to CAM. Multiple tool paths, genuine 3D cutting. Moving the work between paths etc. Its like going from juggling 3 balls (2.5d) to 5 balls (3D).
I haven't seen any competitive opensource CAM products, and its the main reason I continue to use Fusion 360 instead of OpenSCAD or SVG for my designs.
> I haven't seen any competitive opensource CAM products...
Solvespace is open source and claims to export tool paths as gcode with cutter radius compensation, though I have not used this feature. I found cutter radius and export 2D section but it's not cooperating right now!
http://solvespace.com/index.pl
Solvespace is open source and claims to export tool paths as gcode with cutter radius compensation, though I have not used this feature. I found cutter radius and export 2D section but it's not cooperating right now!
http://solvespace.com/index.pl
> preparing CAM data — export 2d vector art for a waterjet machine or laser cutter; or generate STEP or STL, for import into third-party CAM software for machining
Thats been my experience with all of the OSS CAM: g-code for 2.5D, or STL so that a 3rd Party can do the really heavy lifting.
Thats been my experience with all of the OSS CAM: g-code for 2.5D, or STL so that a 3rd Party can do the really heavy lifting.
Done it:
http://nraynaud.github.io/webgcode//various_tests/test_3D.ht...
to me the hard stuff is 5 axis with tool vectoring and collision avoidance.
to me the hard stuff is 5 axis with tool vectoring and collision avoidance.
Have a look at FreeCAD Path Workbench. You won't use it to run your 200000$ 5axis mill, the 3d kernel has limitations, and the UI isn't polished and has rough spots, but it is usable.
I've been looking for a home PCB machine and would appreciate any recommendations on what to look at or what to avoid.
I've been told multiple times that it's easier to just have a service print your board which is probably true, but that would take a lot of fun out of the entire process for me.
I've been told multiple times that it's easier to just have a service print your board which is probably true, but that would take a lot of fun out of the entire process for me.
I've been using a 3018 CNC with pretty good results. They're fairly inexpensive machines (about $300 I believe) and are decently accurate.
I still order boards from China, but for a quick breakout board it's incredibly handy!
I also decided to get a 5W laser which is also pretty fun to engrave with.
I'm planning on writing a series of blog posts about it if you're interested!
As a last note, if you like tinkering, these little machines are money and time sinks.. So far, I've added limit switches, a pi, more bits, 3D printed a tool holder etc etc
I still order boards from China, but for a quick breakout board it's incredibly handy!
I also decided to get a 5W laser which is also pretty fun to engrave with.
I'm planning on writing a series of blog posts about it if you're interested!
As a last note, if you like tinkering, these little machines are money and time sinks.. So far, I've added limit switches, a pi, more bits, 3D printed a tool holder etc etc
I'm definitely interested. I got into 3D printers and CNC machines at about the same time last year. I figured out the 3D printer right away and quickly went from printing out things on thingiverse to doing my own designs and outgrowing my printer and getting a fancier one.
While I've done about 250 print jobs in just under a year on my 3D printers after 8 months with the CNC I've cut two things. I got an entry level CNC (Millright M3) that runs the same GRBL on Arduino software stack and I've just been stumped after setting it up and cutting a couple rectangles out. The amount of time you have to put into setting up a CNC job is exponentially more and the amount of reference material out there is way less and way more specific to particular work flows / machines / pieces being cut.
While I've done about 250 print jobs in just under a year on my 3D printers after 8 months with the CNC I've cut two things. I got an entry level CNC (Millright M3) that runs the same GRBL on Arduino software stack and I've just been stumped after setting it up and cutting a couple rectangles out. The amount of time you have to put into setting up a CNC job is exponentially more and the amount of reference material out there is way less and way more specific to particular work flows / machines / pieces being cut.
There's a big difference between an additive process vs subtractive process. To me, additive is much easier as it starts at the bottom and build up. Nothing is ever in the way of the next step. Subtractive is much more difficult as you have to figure out how to get to places that needs tooling, how to hold the piece to do the work on it (especially as the piece changes shape in the process). Most projects I work on requires more work in setup than actual milling/cutting/etc. It's one of those things that most people just don't realize until they actually attempt it.
I've found the work holding on the CNC to be somewhat analogous to bed adhesion on the 3D printer. When milling you have to figure out how to hold this block down and printing you're using glue sticks and tape to try to get the first layer to stick. Both of these require the same trial and error shade tree mechanic skills that I enjoy developing.
My sticking point is more in the CAM side of things.
First I'll design something in Fusion 360. If I want to 3D print it the next steps are to export the stl (shape file) and open it in a slicer program. Then there are about ten parameters that may need some tweaking especially for a new printer and dozens more that you rarely change from the default before sending gcode to the printer. The slicer program can get you pretty close out of the box and the more I've done it the less time I spend slicing - my go-to settings print perfect 90% of the time. There are lots of resources (blog posts, youtube videos etc) explaining the different slicer settings and their effects on the print.
For CNC Milling after I've designed the part in F360 you switch over to CAM mode and it's like an entire different project that you have to design. With the slicer you say "lay it down on this side and print in PLA" the CNC CAM process makes 0 decisions for you. You can't just say "here's my stock, here's my end mill, put this side up and cut" and then tweak settings from there. Instead there are myriad permutations on feed rates, orders to cut things, multiple passes. Someone's feeds and speeds posted on the internet aren't going to work for your machine/material/design so there can't be something like a slicer program that can automatically route your CAM based on a few parameters and you can't reuse many settings between jobs.
I still like both printing and milling but milling is such a more difficult task with less mature software available (especially open source and hobby level software). That's why a fairly simple task warrants a pretty lengthy tutorial that's worthy of the HN front page.
My sticking point is more in the CAM side of things.
First I'll design something in Fusion 360. If I want to 3D print it the next steps are to export the stl (shape file) and open it in a slicer program. Then there are about ten parameters that may need some tweaking especially for a new printer and dozens more that you rarely change from the default before sending gcode to the printer. The slicer program can get you pretty close out of the box and the more I've done it the less time I spend slicing - my go-to settings print perfect 90% of the time. There are lots of resources (blog posts, youtube videos etc) explaining the different slicer settings and their effects on the print.
For CNC Milling after I've designed the part in F360 you switch over to CAM mode and it's like an entire different project that you have to design. With the slicer you say "lay it down on this side and print in PLA" the CNC CAM process makes 0 decisions for you. You can't just say "here's my stock, here's my end mill, put this side up and cut" and then tweak settings from there. Instead there are myriad permutations on feed rates, orders to cut things, multiple passes. Someone's feeds and speeds posted on the internet aren't going to work for your machine/material/design so there can't be something like a slicer program that can automatically route your CAM based on a few parameters and you can't reuse many settings between jobs.
I still like both printing and milling but milling is such a more difficult task with less mature software available (especially open source and hobby level software). That's why a fairly simple task warrants a pretty lengthy tutorial that's worthy of the HN front page.
I might be a dreadful old fogey, but I think that everyone should learn manual machining before getting into CAD/CAM. There's a level of mechanical sympathy that can only be learned by turning the handwheels and making chips. CAM is complex because machining is complex - removing the software from the equation makes it far easier to learn the fundamental principles, IMO.
I've started adding some posts about the CNC upgrades here: https://nadav.ca/2019/01/18/list-of-3018-cnc-upgrades/
It's still a little bare, but I'm hoping to add more detail as I can. Feedback is also very much appreciated!
It's still a little bare, but I'm hoping to add more detail as I can. Feedback is also very much appreciated!
Thanks! I would def love to read your posts about this.
I have a 3d printer at home that i picked up a couple years ago, so I know how much of a time sink these things could be. Regardless, every time I print something, it makes up for all the lost time/money.
I have a 3d printer at home that i picked up a couple years ago, so I know how much of a time sink these things could be. Regardless, every time I print something, it makes up for all the lost time/money.
Absolutely! I recently got a 3D printer as well and the feeling of being able to create something "out of thin air" is amazing.
Hopefully I'll have something initial up this weekend, i'll post the link here when I do.
Hopefully I'll have something initial up this weekend, i'll post the link here when I do.
I have the same CNC including the laser and decided to upgrade it with a 3D printer head. I attached an Arduino to the wire normally connected to the spindle motor and translated the signal into a PWM signal for the extruder. Temperature was controlled using the same Arduino.
Yes, it worked and yes, it took the better part of a month of work. But definitely fun and educational.
Thank you. I too have been looking at one of these for PCB milling. Do you mind sharing the kinds of boards you have created with it? Are any of them KiCad projects on GitHub?
They're not, I wasn't focused on documenting when I created them. I'll be sure to add that to the list of things to share :) But here is an image of an SOIC-20 I milled. https://pasteboard.co/HX2z3EN.jpg
The short version of the workflow is: FlatCAM to convert gerbers to gcode then CNCjs on an orange pi zero to stream the gcode to the CNC.
The short version of the workflow is: FlatCAM to convert gerbers to gcode then CNCjs on an orange pi zero to stream the gcode to the CNC.
It's not just that it's easier, but you can get much finer detail, you don't have to deal with vias, and you can do more than two layers. And (big plus in my book), you don't have to deal with the inevitability of breaking those insanely small end mills.
The only benefit over having a board shop do it is the turnaround time, and even that's essentially a tradeoff of time vs money.
I just sent a board off to OSHPark. 3.5"x2.3" two-layer board for essentially $15 each.
The only benefit over having a board shop do it is the turnaround time, and even that's essentially a tradeoff of time vs money.
I just sent a board off to OSHPark. 3.5"x2.3" two-layer board for essentially $15 each.
This is all true. The biggest deal breaker for any kind of serious work is being constrained to two layers, routing is so much harder that way!
Milled PCBs also have lousy surface quality which is incompatible with fine pitch parts.
Milled PCBs also have lousy surface quality which is incompatible with fine pitch parts.
Surface quality on milled PCBs can be pretty good but you have to get a bit spendy. Also, the copper FR4 likes to delaminate under stress and deforms easily if you use the wrong cutting parameters so you typically want to go for a higher quality board material. It's pretty common for high end RF boards to be milled.
Being able to have prototypes in hand in like 30 minutes is the best thing about PCB milling. You can make boards for fine pitch parts as well - the board has to be probed and leveling applied to the GCode. We're using 3040Z CNC which is not the best for this job but manageable.
Check out my tutorial (gallery on the bottom) https://wiki.base48.cz/PCBMilling
Check out my tutorial (gallery on the bottom) https://wiki.base48.cz/PCBMilling
I've yet to see anyone make a test board on CNC that wouldn't have been made quicker and with better quality by using photoresist boards and etching them. And I have a pretty decent CNC mill.
Anything with non-trivial edge cuts are advantageous to do on a CNC mill.
Of course one can also combine, as long as one has the registration skills.
I owned a 3020 and own a Shapeoko 2. Unfortunately, I rarely use them. The biggest problem with CNC is that the overhead is so expensive. There's very little room for mistakes and material cost (stock and bits) can get very expensive. Holding a part can get tricky and the wrong feedrate can ruin your part. I end up using my 3D printers to do most of my parts nowadays. Though I do use my CNC for "food grade" stuff around the house.
> ...and material cost (stock and bits) can get very expensive.
I've been looking at CNC for a long time, and I've read that if you're starting from scratch, to allocate about the same amount that you spend on the mill itself to the consumables/logistical tail (end mills, cutting fluid, ancillary metalworking tools). Due to the steady degradation of quality design and manufacturing, and rapid support obsolescence, there is an endless supply of improvements I could make around the house if I had enough time and equipment.
It bothers me greatly to hear from appliance repair techs that I must throw out an entire major appliance instead of repairing just the pieces that broke [1], because the parts are either grossly expensive, or even simply not available. I'd love to own "versioned, open source" appliances, where open specifications let everyone repair only what breaks. And when something breaks, the community can figure out the root cause and redesign for greater robustness.
Like if a plastic part wears down causing a cam to miss a gear, then redesign to machine the cam out of high strength steel. Or if lots of people note a design oversight that makes a particular maintenance procedure a pain, a different access panel is designed and distributed for machining. Or if someone wants upgrade to a later version of an appliance, they swap out only the guts that change, and not the entire assembly, ideally sending the old guts in for recycling back into feedstock that others use for either manufacturing new or upgrading old units themselves. Or building in self-diagnosis over time, and auto-ordering new components for those that are detected wearing out.
The Increvable washing machine comes close [2] in the repairability area, but it isn't open source to the point where you can read off specs to create completely compatible machines, and the company can still go after you for copying their product.
[1] https://circuitmaker.com/blog/about-open-source-washing-mach...
I've been looking at CNC for a long time, and I've read that if you're starting from scratch, to allocate about the same amount that you spend on the mill itself to the consumables/logistical tail (end mills, cutting fluid, ancillary metalworking tools). Due to the steady degradation of quality design and manufacturing, and rapid support obsolescence, there is an endless supply of improvements I could make around the house if I had enough time and equipment.
It bothers me greatly to hear from appliance repair techs that I must throw out an entire major appliance instead of repairing just the pieces that broke [1], because the parts are either grossly expensive, or even simply not available. I'd love to own "versioned, open source" appliances, where open specifications let everyone repair only what breaks. And when something breaks, the community can figure out the root cause and redesign for greater robustness.
Like if a plastic part wears down causing a cam to miss a gear, then redesign to machine the cam out of high strength steel. Or if lots of people note a design oversight that makes a particular maintenance procedure a pain, a different access panel is designed and distributed for machining. Or if someone wants upgrade to a later version of an appliance, they swap out only the guts that change, and not the entire assembly, ideally sending the old guts in for recycling back into feedstock that others use for either manufacturing new or upgrading old units themselves. Or building in self-diagnosis over time, and auto-ordering new components for those that are detected wearing out.
The Increvable washing machine comes close [2] in the repairability area, but it isn't open source to the point where you can read off specs to create completely compatible machines, and the company can still go after you for copying their product.
[1] https://circuitmaker.com/blog/about-open-source-washing-mach...
Sometimes those plastic gears are serving a purpose though. They can protect much more expensive parts by failing first when an error occurs.
So the operators gripe about replacing a stupid plastic gear so they replace it with a metal one, then gripe when they have to replace the blown out gearbox.
So the operators gripe about replacing a stupid plastic gear so they replace it with a metal one, then gripe when they have to replace the blown out gearbox.
Yep, thanks for pointing that out to the general audience, should definitely be noted. Some KitchenAid mixers have a plastic gear for exactly that purpose. On the other hand, on an outboard motor I use, the plastic gear that wears through for a tilt lock mechanism is attached to a ludicrously expensive metal assembly that has to be completely replaced.
I'm okay with the plastic gear designed as a sacrificial component. I don't like having to toss an entire assembly into the landfill, though. I'd like to be able to print/purchase just the sacrificial component and screw/glue it onto the existing still-working assembly. Event better, I'd like to send the broken sacrificial component back through to a process that breaks it back down into feedstock for recycled resins that go to manufacture products that can take slightly weaker plastic (each pass through recycling, plastic becomes slightly weaker, with virgin plastic starting at the strongest).
Ideally, I'd like to see aluminum parts that are designed to crumple under the specified sacrifice load like the equivalent plastic parts, and be able to just endlessly recycle the aluminum. But I've never seen such a design of a sacrificial gear/cam/bolt, so I don't know if that is simply an impossible mechanical engineering ask by a dumb layperson.
I'm okay with the plastic gear designed as a sacrificial component. I don't like having to toss an entire assembly into the landfill, though. I'd like to be able to print/purchase just the sacrificial component and screw/glue it onto the existing still-working assembly. Event better, I'd like to send the broken sacrificial component back through to a process that breaks it back down into feedstock for recycled resins that go to manufacture products that can take slightly weaker plastic (each pass through recycling, plastic becomes slightly weaker, with virgin plastic starting at the strongest).
Ideally, I'd like to see aluminum parts that are designed to crumple under the specified sacrifice load like the equivalent plastic parts, and be able to just endlessly recycle the aluminum. But I've never seen such a design of a sacrificial gear/cam/bolt, so I don't know if that is simply an impossible mechanical engineering ask by a dumb layperson.
This is largely the difference between hardware projects (not just electronics -- metal and wood as well) and software. Decent quality physical things and materials can't be downloaded and reused indefinitely.
The Mostly Printed CNC is another great 3d printed CNC. https://www.v1engineering.com/specifications/ Almost done printing the parts for mine. Will run GRBL on it as well.
I've been looking into building my own CNC. Sounds like there are some experienced CNC peoople here. Does anyone know why there are not more polar coordinate based CNC machines? I've been wondering what the pros and cons are.
Probably because the compliance changes. The farther you go from the origin, the easier it is to push the tool away from its intended cutting path.
A gantry-style machine, on the other hand, has the same rigidity anywhere in the X-Y plane. Rigidity is a bit less as Z changes (due to a longer moment arm), but it typically doesn't travel as far.
A gantry-style machine, on the other hand, has the same rigidity anywhere in the X-Y plane. Rigidity is a bit less as Z changes (due to a longer moment arm), but it typically doesn't travel as far.