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

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

Post by unicornswag » Tue Apr 22, 2014 3:41 pm

twforeman wrote: 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.
That was exactly my point. Manual editing of slicer-generated g-code in rapid prototyping is extremely rare and nearly impossible, and handwriting or hand-editing code used in milling is getting more rare too. It is normally far easier to leave this to CAD/CAM.

Essentially what I'm saying is that if g-code is on the road to becoming a practically non-human-readable list of commands, then maybe it wouldn't be entirely unreasonable to consider a more efficient non-human-readable protocol to take stress off the controller.

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 4:51 pm

"take the stress off the controller"

You are looking for a solution to a non-existent problem. There is nothing wrong with having a custom controller that reads G code and drives the CNC machine. In fact, based on all the different variations of machines out there, it would be a lot of work to make a program that would output steps to drive them. Not to mention that many CNC machines don't use stepper motors, but rather have servos with encoders and feedback loops.

There is a lot of math that happens on the controller boards for a standard CNC machine, nd then there are machines like this:



Just imagine the math required to drive 6 lead screws simultaneously to cut a straight line. And all you have to do is send the machine controller a G code like "X 10 Y 15" and it does the math for you.

If you want to take a specific machine, and modify it to run as you are describing, more power to you. But the rest of the CNC world will continue using G code and on-machine controllers for interpretation.
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 » Tue Apr 22, 2014 6:06 pm

Not least because that controller is an interpreter, which is vital, and a buffer, also vital, & practically bulletproof. Which is also vital when cutting a big block of exotic material that could well have cost thousands.

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 » Tue Apr 22, 2014 6:11 pm

I think Unicornswag's point is that G-code is not ideal for 3D printers, and a different format may be better. I think Repetier does something along those lines: while the slicer still outputs G-code, Repetier Host parses it and transforms it into a much more compact protocol for Repetier Firmware. It's still the firmware that calculates and generates the step pulses, so it's not the same thing that was discussed here, and not the same thing that Mach3 does when used with a SmoothStepper.

Still, even for 3D printers, G-code is here to stay. It's not nearly as bad as some make it to be.
Proud owner of ShapeOko #709, eShapeOko #0, and of store.amberspyglass.co.uk

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 » Tue Apr 22, 2014 9:21 pm

It is pretty terrible, but at the end of the day you don't have to handle it much if at all. Layers of an stl that's been sliced up aren't something you'd ever touch. However you could go in and chop it manually so you print the first 120mm then the next 105mm then glue them together to get around the fact your printer is only 150mm tall. All you need to do is locate the start of the model so the raft still works.

A dedicated step-aware bit of code (akin to compiled?) could be treated exactly the same though you'd need to guess where you were as you'd need to keep track of every step and movement. (Could still do it from the line numbers though, in a decent editor. )

Sent from my SM-N9005 using Tapatalk

dcartier
Posts: 16
Joined: Mon Feb 17, 2014 6:53 pm
Location: Brampton, Ontario

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

Post by dcartier » Wed Apr 23, 2014 10:41 am

I also have been somewhat disappointed at the state of opensource Cad/Cam. However what I think needs to be done is slightly different. My suggestion on how to address the situation would be to improve the existing 2D and 3D solutions (E.g. makercam and pycam) to expand their capabilites and remove limitations. The stages I normally try to reach in coding is 1. make it work, 2. make it good, 3. make it fast. Both the mentioned packages have either not passed stage 1, or are only slightly past it depending on your perspective. As to the language, I would strongly suggest that an interpreted language (Python, Java, etc.) be used until it becomes the limiting factor (E.g. Stage 3) in the expectation that it will allow for greater participation in the community effort.

I also agree with the others , Gcode is not the issue and does a fine job, and our opensource solutions (GRBL, LinuxCNC) are very good.

I suspect we find ourselves in this situation from a lack of interested parties willing to devote their time and energy to addressing the situation.

Dennis

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

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

Post by unicornswag » Wed Apr 23, 2014 6:53 pm

Okay, I think it's become clear that my initial ideas on the issue were a bit radical. However, one aspect where 3D printing G-code currently differs from milling G-code is the fact that rapid prototyping slicers and firmwares do not make use of arcs. As far as I know, the only RepRap firmware that has the ability to interpret G02 and G03 codes is Marlin. Maybe in the near future CAM for CNC milling will begin taking a similar approach. With that setup, many operations on the controller would be simplified, the code would be somewhat understandable if viewed by the user, and it would maintain backwards compatibility with existing machines. This setup is essentially one step above my original idea, as it is basically just a list of coordinates for the toolhead (or extruder) to move to at a certain speed, but ultimately lets the controller firmware make the final interpretations based on the specific machine. I think it would definitely be nice if Extrusion and subtractive milling operations could both be designed and executed using the same software toolchain.

In regard to the point made about Delta robots and other complex mills, I'm not really sure how that helps the case of keeping with G-code, as currently the most major limiting factor for Delta designs is the fact that the complex triginometry needed to be carried out on the microcontroller is pretty insane, hogging resources and making the machine's movements inaccurate. In those cases, the control code really needs to be simplified as much as possible on the host computer.

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 » Wed Apr 23, 2014 7:09 pm

unicornswag wrote:However, one aspect where 3D printing G-code currently differs from milling G-code is the fact that rapid prototyping slicers and firmwares do not make use of arcs. As far as I know, the only RepRap firmware that has the ability to interpret G02 and G03 codes is Marlin. Maybe in the near future CAM for CNC milling will begin taking a similar approach. With that setup, many operations on the controller would be simplified, the code would be somewhat understandable if viewed by the user, and it would maintain backwards compatibility with existing machines.
And you'd get nasty artifacting and unsmooth curves.

Please read G codes for the specification of Pythagorean-hodograph tool paths available at: http://mae.engr.ucdavis.edu/~farouki/ijmtm99a.pdf
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

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 » Wed Apr 23, 2014 8:11 pm

The main reason slicers don't use arcs is that they slice STL files, which have no curved surfaces at all -- they're made of (flat) triangles. These, inherently, produce only segments when sliced, and, as I often see when the designer did not bother to adjust the $fa etc. variables in OpenSCAD, results in parts with ugly, visible facets where there should be a nice curve. The slicers should, ideally, generate arcs where needed for the fill (e.g. when U-turning in a solid fill).

Again, eliminating arcs is at cross-purposes with data locality and breaks abstraction: instead of letting the machine controller chop them up internally at a resolution that it knows makes sense for the machine, you have to make the assumption about how finely to divide the arcs at the point where the NC is created, that is, in CAM (or slicer). We strive toward portability and machine independence in CAM (and NC code), because it makes our lives simpler -- not the other way.
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 » Wed Apr 23, 2014 10:37 pm

Are there any slicers that can slice IGES or STEP files? Those formats can contain curved surfaces.

Post Reply