CNC milling with open source software
opensource.com
opensource.com
Some firmwares support arcs (smoothieware, which is based on GRBL) but it still breaks the arcs down to segments.
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 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.
Steppers are great, but anything big needs a servo, as the steppers get to expensive and too slow very quickly.
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.
Anything bigger, many people seem to like ClearPath servos. Price to performance seem to be pretty good.
I'd think it would be useful to integrate the two, instead of the CAM software just firing-and-forgetting toolpaths.
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?
(Both are these are solvable, it's interfacing with the machine in any standardized way that is not)
Your question is somehow similar to "why can't the C code directly control the CPU"?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Check out a simulator here: https://www.ncsimul.com/
How aware? Do they have any vision? Can they "see" or otherwise "know" about the cutters / workholding?
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.
If the supports/bars are in the overlay, the operator DOES NOT run that part and takes it back to design.
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.
Certainly a chicken and egg problem though, my ideal future would have CAD files generated from single source of truth CNC files:)
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!
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.
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!
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!
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.
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.
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.
Much sadness will ensue.
But that still doesn't help in case of insufficient workholding or breaking tools.
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.
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.
Do you manually monitor the entire job cycle?
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).
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.
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?
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.
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 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
Also, latest FreeCAD has a CAM module ("Path workbench") that has come a long way and really is useful.
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
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 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
>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?
go_home
set_units mm
set_movements relative
activate_tool 0
move X 10
move Y 10
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...
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.
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.
Asking, because I am trying to level up cnc programming to "normal" programming.
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.
Compilers targeting G-code are called CAM software.
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
https://carbide3d.com/shapeoko/
:)
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.
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!
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.
to me the hard stuff is 5 axis with tool vectoring and collision avoidance.
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 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 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.
Hopefully I'll have something initial up this weekend, i'll post the link here when I do.
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.
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.
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.
It's still a little bare, but I'm hoping to add more detail as I can. Feedback is also very much appreciated!
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.
Milled PCBs also have lousy surface quality which is incompatible with fine pitch parts.
Check out my tutorial (gallery on the bottom) https://wiki.base48.cz/PCBMilling
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...
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.
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.
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.