Hacker News Reader

Comment by brookst | Hacker News Reader

It’s very cool, but not novel. I’ve been using Rhino / Grasshopper to design toolpaths rather than objects for years, and the technique far predates me.

I think integrating toolpath design into cad makes more sense than using Excel as an intermediate layer.

View on HN

Interesting.

I've long been frustrated by traditional CAD/CAM, so finally worked up:

https://github.com/WillAdams/gcodepreview

which allows me to use:

http://pythonscad.org/

and:

https://github.com/derkork/openscad-graph-editor

to create joinery:

https://forum.makerforums.info/t/openscad-and-python-looking...

which would otherwise be tedious to draw up:

https://community.carbide3d.com/t/creating-drawers/19475/26

Fullcontrol has moved away from using excel to using python code in jupyter notebooks.

If we are being pedantic; this is the point of gcode itself. It is designed to be easy for a human to write. Having more tools available though can never hurt.

The problem is, the most widely available G-code interpreter at the hobbyist level/price range lacks variables, loops, or branches --- writing anything in it is tedious to say the least, evoking:

https://www.folklore.org/StoryView.py?story=Discovered_Loops...

Gcode is like assembly language: yes, it is human readable as compared to byte code, but it is way too low level to work in.

I write software that generates gcode for things like vases and mugs. The gcode for a typical print is between 200KB and 2MB. It would be impossible to hand code at any decent level of productivity.

Do you make use of loops and variables and branching?

Folks get an awful lot of work done using G-code thus, incl. work on lathes which few CAM programs would handle with aplomb, let alone the same mathematically correct efficiency.

Using gcode on a lathe or other subtractive machine is ORDERS of magnitude more productive because orders of magnitude less code is required because orders of magnitude fewer operations are required.

With a subtractive process you typically only need to put a few holes into specific locations using a cutting tool roughly the same size as the hole. Jog over, plunge, jog over to the next site, plunge. Maybe you need to mill out a few pockets or an exterior shape, in which case you switch to an endmill that's good for mass material removal and perform 2-3 passes around the outline's polygon.

And then there are additive processes that 3D printers use. Try to back-of-the-envelope how many passes of the tool head are required to build a 5x5x5cm cube using a hotend that has an orifice of 0.0004 cm and a layer thickness of 0.0002 cm. It's a lot of passes, and because gcode was designed for the subtractive processes where only a few passes are typically required, it contains zero macro commands for doing it in fewer lines of code. If you want to infill with a fancy material-saving pattern, the complexity of the movements required goes exponential and so does the LoC.

I use loops and branching, but way up in the Grasshopper programming layer, not gcode. My work is things like https://www.instagram.com/p/CZrtHC_px1D/ , where the modulations happen at so many layers that it's much easier to generate gcode from a higher level programming language.

Plus it's nice to be able to visualize a piece in CAD before generating the gcode.

Reply on news.ycombinator.com