FullControl: Unconstrained gcode design for 3D printers | Hacker News Reader

FullControl: Unconstrained gcode design for 3D printers

github.com

73 pointsfanf228 comments

I really hope someone explores this with multi-axis printing. 3D printers have become impressively reliable and work great, but we are in a local maximum: we print in 3 axes only, layer by layer. You could do so much more with a tilting bed (4th axis), or a tilting extruder (4 and 5).

As I recall, A and B axes have been done, as well as cylindrical/lathe printing. These just haven't made it into consumer 3d printers.

Fairer to say that they print in only 2.5 axes, rather than 3.

They have some 5 axis stuff basically as a coming soon teaser.

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.

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.

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

This looks great. Can someone explain the implications of manipulating gcode directly?

I like the convenience that OpenScad and the slicer take care of translating my shape into instructions for the printer.

With FullControl, will I still be able to describe a shape and it gets done, or do I have to think in printer movements rather than 3d forms?

Sounds like you need to think in printer movements. And you have to use excel and Visual Basic to input them.

They are focusing on Python now.

Yes this is for when you want to think in movements.

When slicing a 3d shape the are multiple different ways the head can move to create the same shape. Slicers account for some of these with features like 'Spiral Vase' where instead of having a stack of horizontal circles you can instead continuously spiral the extrude up the vase. FullControl lets you have even more control.

whats the rationale for writing technical documentation like its a series of casual text messages

maybe they're trying to entice someone with keen documentation knowledge to their project by means of git collaboration?

hint hint.

No, I think it's written like that on purpose.

I'll bite! Same as event sourcing - it's thread-safe.

I find, when updating docs, that is easy to miss a paragraph and leave obsolete info. Then you have invalid state. If you merely post updates, then accurate state can always be reconstructed by replaying the log. The cost is that replaying is more expensive.

Likewise, if you're busy, it might suit you to chuck an update at the doc rather than take care over it. It's probably not so good for the doc, but better than not updating the doc. Startup mentality <taps head>

There's not much in those screenshots that doesn't look like it was done with a normal slicer or couldn't be banged out in five minutes in Notepad in raw gcode. Like one of them seems to just be some gyroid infill with walls and roofs set to zero.

> Like one of them seems to just be some gyroid infill with walls and roofs set to zero.

That works only for existing infill patterns. The idea is that if you wanted to create a completely new infill pattern,you could first prototype it using FullControl before implementing it in a slicer.

> or couldn't be banged out in five minutes in Notepad in raw gcode.

That's the point this just a slightly more convenient method for generating gcode.

Manual typing in notepad has it's limitation, as there is only so much text you can type. So you will want some kind of scripting language supporting loops and expression evaluation, so that repetitive parts can be described more easily. Some more advanced gcode interpreters even have extensions that allow you to do loops and calculations directly within the GCODE. But I don't think any of widely used 3d printer firmwares have that or support it too well. There are a couple of benefits doing it on computer in a general purpose language:

* GCODE wasn't exactly designed as general purpose scripting language so for more complex stuff syntax isn't that great compared to python

* performance and ability to plan ahead. If 3d printer evaluated and executed each gcode instruction independently it would result in very choppy movement as the tool accelerated and stopped for each of them. Most modern 3d printer firmwares will plan the movement acceleration across the multiple gcode instructions. That's not easily doable if the future gcode instructions depend arbitrary logic. It's simpler to split it into two parts so that 3d printer only needs to care about linear sequence of instructions with no loops, branching or complicated calculations.

* People always make mistakes. Pregenerating the sequence of gcode on computer, allows you to simulate and verify it on computer before running on actual device.

You could also just generate the GCode directly as plaintext from scripting language of your choice. But again this is just a bit of convenience allowing you to skip of the boilerplate for most common actions and transformations.

> There's not much in those screenshots that doesn't look like it was done with a normal slicer o

From what I see those pictures:

* gyroid like looking thing -> already explained before

* surface texture patterns -> some slicers have builtin functionality, but again it doesn't help if you are prototyping new surface texture pattern

* complex single wall thickness shapes -> there is vase mode but it only works for external contour, and attempting to slice single wall thickness model without vase mode wouldn't work well either

* grid of lines on build plate -> probably some kind of test pattern for finetuning one of the printing parameters

* single extrusion thick tower with bridging

* very thick extrusion beads forming a braid like pattern

* more single extrusion thick latices

* non planar movement

* spool shaped object -> 90 degree overhangs

Fullcontrol & SimpleFOC based interaction or robotics is something that's extremely piqued my interest in electronics

So if I know my printheads dimensions I can for example print a far away island part of the model first binding the part better together?

The easiest way to do this is simply to slice two files and concatenate the gcode.

Most slicers have a mode to print "object by object", allowing this.

I wish slicers had an even smarter mode: Reduce free-space moves. When printing a castle with 4 turrets, the slicer could be smart enough to know that after printing the main part of the castle, it can then print the turrets one at a time because they won't hit the print head.

If the turrets were a bit taller, and would collide with the print head, then you could still print half of all the turrets, followed by the other half of all the turrets.

End result: Less print time, less retractions, less moves over free space (stringing).

And better adhesion due to less cooldown

Reply on news.ycombinator.com