What is the Future of the opensource CNC Toolchain?

Talk about all things CNC
unicornswag
Posts: 32
Joined: Thu Apr 03, 2014 1:51 pm

What is the Future of the opensource CNC Toolchain?

Post by unicornswag » Mon Apr 21, 2014 4:52 pm

So I'm 17 and recently started out with CNC milling and rapid prototyping. I am a strong advocate of all things opensource, and honestly, the options currently available for a free CAD / CAM toolchain are mediocre at best. In fact, most of the "opensource" options listed in the Shapeoko wiki are either crippleware or some Java bloatware. On top of this, these tools all rely on G-code, which has now been in use for over 50 years. Obviously it has stood the test of time, but for the most part it has become a fairly cryptic language in the world of modern CNC.

I hope that within the next 10 years, the opensource CAM situation will improve significantly. My current knowledge of CNC, as well as my programming skills are still a bit limited, but someday I would like to play a part in improving the toolchain. So currently, this would be my basic criteria for the ultimate opensource CAM software:

1. It would be written purely in C to be extremely lightweight and universal across OS'es

2. It would be usable purely from the command line, with the ability to act as a back-end to an external GUI.

3. It would be equally useable for subtractive milling as well as additive rapid prototyping .

4. G-code would be eliminated in favor of NC code "compiled" for a specific machine. The NC code would essentially be no more than a commented list of step and direction signals to be pulsed to the machine's steppers. This would simplify the microcontroller machine controller exponentially. The microcontroller firmware would essentially act as merely a buffered serial-to-parallel interface.

So, my question is, does this look like a reasonable toolchain of the future? Would the necessity of "compiling" NC code to a specific machine be a major drawback when compared to the portability of G-code? I know that there has been some discussion of grbl heading in this direction to take lessen the load on the microcontroller. So what is your idea of the ideal CNC toolchain of the future?

WillAdams
Posts: 8628
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by WillAdams » Mon Apr 21, 2014 5:56 pm

While I appreciate youthful enthusiasm as much as the next guy....
Those who do not understand Unix are condemned to re-invent it, poorly.
--- Henry Spencer (https://groups.google.com/forum/#!msg/s ... 6ngTI0K0QJ)
This stuff is hard --- read back through the OpenSCAD mailing list for some discussion of the underlying geometries and their issues.

If you want a project which is likely w/in scope for your capabilities / understanding / ambition, my suggestion would be to take the MakerCAM source code and port it to an opensource platform --- JavaScript and the HTML5 Canvas should be a suitable space, and you may find the paper.js library of use.

There was also ISTR a blind machinist who had written up some code and was interested in finding someone to pass it on to --- I posted the link here and cvoinescu expressed some interest, but I don't know if he ever followed up.
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

twforeman
Posts: 1351
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by twforeman » Mon Apr 21, 2014 6:06 pm

Let me clear up a misconception.

CAM software does not "run on G code", it produces it. G code is what the actual CNC mills run on, and it's used on 99.9% of all existing and future CNC machines.

As you say, it's a bit cryptic. But it gets the job done, and to replace it would obsolete most of the existing CNC machines out there. There is no pressing need to replace it that I am aware of. I know that when you are 17, something that is 50 years old seems ancient. But when you are 50+ years old, like me, you might think differently. :)

I agree with you that the existing open source CAD/CAM software is lacking. There are a few out there that work okay, LibreCAD is a good 2D package and runs cross-platform. I have not yet found a good open source solid modeler.

As for CAM software, I have not found any open source that I like.

As for your suggestions, I'll say this:

1. The language is immaterial. C is only cross-platform if you are very careful to make it so.

2. While I am a huge command line guy, I can't see the point in running a CAD or CAM package from the command line. There is no way I would want to try and design something using CLI. When you are doing full 3D solid modeling, you need to be able to push, pull, drag, etc. If you want to mill simple pockets and holes, sure, I can do that with Perl scripts. But for real design and modeling, you need a GUI.

3. CAD is manufacturing-style neutral. You can design things that are cast, milled, bent, or deposited, it doesn't care. The CAM side is what you are talking about.

4. This is a non-starter in my opinion. There is no point to this. G code is a universal standard. If you need it tweaked for your specific machine, you use a post-processor tweaked for it. What you are proposing is moving the brains out of the CNC controller and back into the PC. There is no point. I'm not sure why you feel the need to 'simplify' the microcontroller. You can get a $50 Arduino and run Grbl on it. It works great. Why does it need to be simpler than that?
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

Nigel K Tolley
Posts: 226
Joined: Sat Feb 08, 2014 4:06 pm

Re: What is the Future of the opensource CNC Toolchain?

Post by Nigel K Tolley » Mon Apr 21, 2014 6:15 pm

If you were a large company, then yes, go for it. As an individual though, it would likely be an impossibly large task.

g code is pretty complex, but it is human readable to a large enough degree that you can work out what is going wrong. It isn't broken either - there is still room for expansion.

The interpreted nature of the g code also helps when transferring from one machine to another. Simple tweaks to rates of feed and checking the axes are the same are likely all that is required to get two Shapeoko (with the same cutters) to do the same thing. Going to another 3 axis machine shouldn't need much more either.

Going with a sort of embedded controller solution would lead to far more issues. Imagine if a bed had been extended, or someone has twin drive motors, or even just a different sized cutter? Everything would break.

I know for a fact that even small automatic key machines use g code. It is everywhere!

Having said that, you could have a go at it. You would need the machine to be forever stable in design, but it could work for some ideas. A robot or a dedicated cutting machine for example.

(Another factor is that a PC can get interrupted or crash during a long run. The controller is less likely to have this issue, being dedicated to the one task. )


Sent from my SM-N9005 using Tapatalk

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by cvoinescu » Mon Apr 21, 2014 6:37 pm

I doubt the "compiled" NC code, as you envision it, is a good idea. As you said, G-code has stood the test of time. Moreover, your approach is unnecessarily limiting, and completely excludes feedback within the machine. Some machines may have servo motors, not steppers; even with steppers, some machines have "smart" motor drivers that are programmed (e.g. via SPI) with a target position and speed, and they drive the motors accordingly -- no pulses in sight. Some very useful G-code operations (not supported by GRBL, but supported by LinuxCNC, Mach3, and a wide array of industrial machines) use spindle-synchronized motion; this is done by reading the spindle position (e.g. using index pulses) and adjusting the axis movement to match. This is absolutely essential for creating threads on lathes, but also for milling machines when used for tapping and so on. If all your CAM software emitted were timed step pulses, spindle synchronization would be impossible. Also, probing cycles would not be possible.

On a more philosophical level, your approach requires knowledge very specific to a given machine to reside far away from it, in CAM software, rather than in the controller of the machine, where it belongs. Using a higher-level language (G-code) to control the machine insulates the CAM software from this knowledge, and keeps the NC code reasonably general. This is a Good Thing. With your approach, if you change from 8x to 16x microstepping, you have to re-generate the CAM files; with G-code, you just change a parameter in the controller and the same old G-code still works perfectly. With G-code, a shop with three different machines from three different manufacturers can run the same G-code on any of the three (if they're reasonably similar in capabilities), but with your approach you'd definitely have to generate one file for each machine. Also, as your cutter wears down (or gets resharpened and loses a fraction of its diameter), traditional machines would use cutter diameter compensation to run the same G-code with a small adjustment to take the tool wear into account; you'd have to run CAM all over again and make a new file.

Now, for low-power processors such as the Arduino Uno, it would be useful for the host to do some of the processing, which I think is what you read about. A similar approach is actually used by Mach3, which can command a low-power processor to emit step pulses, while the PC worries about the higher-level processing. However, in both cases, the starting point is still G-code, and machine-specific configuration is still held with the machine controller, where it belongs, not in CAM.

To put it another way, what you want is to take away my PostScript printer and replace it with a GDI printer. No.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

cvoinescu
Posts: 4442
Joined: Thu Jul 19, 2012 6:50 pm
Location: Camberley, UK
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by cvoinescu » Mon Apr 21, 2014 6:51 pm

Reading what others posted while I wrote my response (I'd been called away in the middle of it), I realized that you got some great responses that I agree with, but nobody explained why CAM can't be done from the command line. Mere slicing for 3D printing can be fully unattended, but CAM can not be. CAD models the desired object, but is agnostic to its method of manufacture. Where CAD ends -- a solid model -- CAM begins. The computer can, at best, make educated guesses about how the operations should break down and how each feature should be machined; but even if it does that -- especially if it does that! -- the user needs to visualize the operations and decide their type and parameters. Even for something as simple as placing holding tabs for a 2.5D profiling operation, you can't rely on the computer to always do it right. How would it know to avoid placing a tab on a surface where the finish is critical, or where it's difficult for you to reach with a file? You have to do it visually. There's no way to forgo the GUI for CAM.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

Enraged
Posts: 230
Joined: Mon Apr 09, 2012 8:29 pm

Re: What is the Future of the opensource CNC Toolchain?

Post by Enraged » Mon Apr 21, 2014 7:19 pm

Gcode isn't going anywhere. It's the industry standard control language for machining. Trying a different control scheme would essentially make billions of dollars of equipment obsolete. Gcode is not cryptic, each code has a specific function, you just need to take the time to learn it. You can easily write simple programs by hand in a text file, it's part of the course I took in my first year at school.

As for opensource software, the reason (in my opinion at least) you can't find opensource software that is as good as the paid stuff (you will be ruined if you used MasterCAM and are now forced to use anything else) is because people are cheap. Very few competent computer programmers are going to write a high end piece of software like CAD/CAM when there is little financial gain. Obviously there are exceptions, look at how good LinuxCNC is now, built by a community of users.

I see more potential in the lower cost programs out there (like Cambam) where the developer is making money to support the development.

If I had $20k to blow I would pick up MasterCAM and Solidworks. The one change that may happen is these high end companies targeting the consumer market with subscription-based packages. Adobe is doing it now, where you can buy different packages, only pay for what you need, and pay by the month. I'd love to get Solidworks, even a basic version, for a monthly fee.

unicornswag
Posts: 32
Joined: Thu Apr 03, 2014 1:51 pm

Re: What is the Future of the opensource CNC Toolchain?

Post by unicornswag » Tue Apr 22, 2014 2:04 pm

As a die-hard open-source advocate, using windows or any proprietary software would be like pulling teeth.

I suppose G-code has become quite a fixture in CNC milling and isn't going anywhere anytime soon. However, I think a toolchain like this would be met with much more acceptance in the 3D printing realm. The G-code output of a moderately complex part from Skeinforge or Slic3r would look like gibberish to even the most experienced CNC operator, especially when non-circular curves come into play. Because of this, the code is rarely if ever altered by the 3D printer operator. Given the choice between thousands of lines of practically undecipherable G-code or a timed list of step/dir pulses, I think the latter would have some clear advantages.

As for my coding experience, I am nowhere near the level required to undertake a project like this yet, but maybe in a few years...

twforeman
Posts: 1351
Joined: Tue Jan 29, 2013 4:51 pm
Location: Minneapolis, MN
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by twforeman » Tue Apr 22, 2014 3:14 pm

While I am a huge open source fan, and as a matter of fact I run this site on a LAMP stack, and my personal and ShapeOko head-end laptops run LinuxMint, there are times when you just have to use Windows software to get the job done.

Windows is the industry standard for running CAD/CAM, and that's what most packages are written for.

As others have stated, writing CAD/CAM software is difficult and most development goes where the money is.

As far as your idea that people would want to manually edit complicated G code, in my experience it's simpler to just regenerate it with your CAM package. Sure, you can tweak simple G code at the machine, and I do, but for 3D surface paths I'm going to be modifying the model and regenerating the G code.
Ender 3 3D Printer
ShapeOko v3 serial #0004 - upgrade thread
All of my ShapeOko related blog posts

WillAdams
Posts: 8628
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: What is the Future of the opensource CNC Toolchain?

Post by WillAdams » Tue Apr 22, 2014 3:30 pm

unicornswag wrote:As a die-hard open-source advocate, using windows or any proprietary software would be like pulling teeth.

I suppose G-code has become quite a fixture in CNC milling and isn't going anywhere anytime soon. However, I think a toolchain like this would be met with much more acceptance in the 3D printing realm. The G-code output of a moderately complex part from Skeinforge or Slic3r would look like gibberish to even the most experienced CNC operator, especially when non-circular curves come into play. Because of this, the code is rarely if ever altered by the 3D printer operator. Given the choice between thousands of lines of practically undecipherable G-code or a timed list of step/dir pulses, I think the latter would have some clear advantages.
Why? How? It would still look like gibberish, and I don't see a case for editing it.
As for my coding experience, I am nowhere near the level required to undertake a project like this yet, but maybe in a few years...
In the meanwhile, some suggested reading:

- Grbl developer blogs: http://bengler.no/grbl / http://grbl.tumblr.com/ / http://dank.bengler.no/?ref=checkpoint
- source code to Grbl: https://github.com/grbl/grbl
- METAFONT: The Program --- you should be able to get this from any decent library, or buy it from: http://www.amazon.com/Computers-Typeset ... 0201134381 or install TeX and Weave it to get a .pdf from: http://www.tex.ac.uk/ctan/systems/knuth/dist/mf/mf.web --- once you have some experience w/ this sort of thing in 2 dimensions, then you can contemplate a third
- if you're not familiar w/ the concept of literate programming, start here: http://www.literateprogramming.com/

I have a water-damaged copy of http://www.amazon.com/Literate-Programm ... 0937073806 --- drop me a private message if it would be of interest to you.

William
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

Post Reply