4 ms·

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.

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.

Karliss 3y ago
> 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

Karliss 3y ago

> 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