[FEATURE REQUEST] Gcode parsing

[bo0tzz]

I don't know how feasible this is, perhaps real-world gcode is too unpredictable, but I think the ability to parse plaintext gcode back into fullcontrol Points etc would elevate fullcontrol from 'just' an awesome and very versatile design library to also be an incredibly powerful tool for gcode post-processing. You could slice a complex model with all the power of a modern slicer, using your existing profiles and doing complex stuff like supports or filament changes, and then take that gcode into a fullcontrol program to warp, scale, and otherwise modify it to your hearts content.

To give a specific example based on what I'm looking to do: I'm trying to play around with https://www.sciencedirect.com/science/article/abs/pii/S0097849318300578 for halftone image printing. My desired approach is to slice a cube in my normal slicer, with infill and multiple walls and, most importantly, a filament change every layer (alternating between black and white) - which is (IMO) too involved to reasonably implement in fullcontrol. Then I want to take this gcode into fullcontrol and adjust the extrusion path of the outer walls to offset it based on an image with the calculations from that paper.

[AndyGlx]

Yes this is something that's long overdue! I have it on my plans for some work related to use of FullControl outside of desktop 3D printing.
The main challenge will be in trying to interpret gcode lines that are specific to certain printers or just not built in to FullControl as objects. E.g. there is not currently a FullControl object to automatically control accelleration. You'd do that with ManualGcode object most easily. It will likely be a simple enough fix to convert any non-supported gcode commands in your slicer code to ManualGcode objects. The only issue is if they do something that FullControl needs to be aware of. For example, switching from metric to imperial units, or from relative to absolute mode for xyz or extrusion.

So, I'll probably implement it, but with some warnings that it will not work for all situations. Also, it'd be really useful if the slicer outputted relative gcode (M83), but that's not always as option.

[KwentiN-ui]

I second this request. Being able to import existing GCODE would allow us to create volume meshes for analyzing slicer results with FEA 🙌🏼

[fullcontrol-xyz]

Noted! And keeping it high up there on my to do list! 🙉😁 I do really want this. Just a bit sceptical about the versatility to handle all the different types of GCode styles that slicers output. I'm really keen to allow FEA for people super easily. Would you be importing an STL model of the extruded lines into a specific FEA package?

[KwentiN-ui]

Awesome to hear! I'd assume that FreeCADs Part and FEA workbenches could work well with this. If you need help with anything from the Python side let me know!

[fullcontrol-xyz]

Thanks. The challenge will be that fullcontrol will effectively output a load of tubular-like extrusions that are not connected. So you'll need to do some work to stick them together, or remesh as a solid outer surface. So I'd get the workflow sorted with a simple helical toolpath from FullControl (you can take one of the demos). Then if you got that working, it shouldn't be too much work to get it working for slicer-generated gcode parsed into FullControl

[KwentiN-ui]

That sound reasonable, I'll try that out first 👍

[KwentiN-ui]

Building a pipeline from GCODE to FEA using existing tools seems to be a pretty bad experience. The closest I got was the following steps:

• use Prusa Slicer toolpath export to .obj for a Mesh with tons of overlapping tubes (would be replaced with this feature)
• import into Blender, slice the model into 2 halves to expose the inner geometry, remesh using voxels and reduce the mesh size
• import into FreeCAD, make part from mesh, make solid, join the 2 halves back together $\to$ FEA

Although this could work in theory, every step on the way might fail for some mesh related reason. Even if it didn't work out well for my usecase I still think GCode Parsing is a nice feature to edit generated GCode and export to stl for product visualizations. For analysis I'd propably be better off modelling the inner structure in CAD though.

[fullcontrol-xyz]

Yeh that's a pretty challenging workflow. It's a little tangential, but if you're happy to work with relatively simple structures initially, you can generate the 3D surface based on the toolpath data. For a helix path with a known centre, and the same number of points on each layer, it's easy to offset each node of the toolpath inwards or outwards (by half line width) and define FEA elements (3D quadrilaterals) based on the inner and outer nodes of points i and i+1 on layers j and j+1...
This links to something I'm quite passionate about, which is designing the toolpath for all aspects of the task at hand. If you want good FEA, you can design a toolpath that is good for printing and good for FEA. In my example above, it's as simple as making sure you have the same number of points on every layer.

But it won't help with importing slicer gcode and doing FEA on it. I do think the simplest option there is to voxelise everything. I've written software to do that based on gcode a few years ago (https://www.sciencedirect.com/science/article/pii/S2214860417304852) and it works well, as shown in the paper, which specifically focuses on higher resolutions that we're talking about here. There was also a slicer called Voxeliser that could do it. My VOLCO approach would also do it if the iteration aspects of it were turned off and it simply filled volumes rather than respecting the requirement for constant-volume.

[KwentiN-ui]

The paper is a real goldmine. I really like that instead of simply voxelizing the toolpath (like I did in Blender) the geometry actually resembles extruded filament given the constraint of constant volume. This really makes me want to try to build my own implementation of this algorithm. Thank you for sharing, and making this research public in the first place!

[fullcontrol-xyz]

No problem, the only issue is that the iterative nature of the volumetric conservation approach means it takes longer to run computationally and that will be an issue for large toolpaths. I used is for relatively simple structures. I know it can be used for larger ones, but maybe not something the size of a benchy. But if iteration is turned off and it just deposits based on the set width/height of extrudates, it would run v quick. There is a github repo for a python conversion of VOLCO, but it's not public yet. It will allow you to design a toolpath in FullControl then directly simulate it in the same environment. Add a basic python FEA solver into the mix, which is fairly easy, then you can directly simulate stress analysis of the designed toolpath in the same environment. Would you be keen to get involved in knocking that out?

[KwentiN-ui]

I am a bit hesitant to attempt this in Python due to performance constraints, though I wouldn't mind insight into the existing VOLCO implementation. From what I've gathered VOLCO could be implemented as a standalone binary to convert GCODE or some intermediary format to a watertight surface-mesh, which can then be passed to i.e. Gmsh or OpenFOAM. Such a binary could still be called by python modules as a subprocess. I am still pursuing my masters degree, and this could be a good time investment on my behalf.

Being a bit of a beginner in systems-level programming languages I had quite a good experience using Rust before (built a simple Rainflow implementation as a python module once). I know that a lot of researchers preferably work with older languages and I wouldn't want to alienate anyone wanting to contribute to a future project. Please let me know if Rust would be a dealbreaker here.

If you and your colleagues are fine with a FOSS implementation of VOLCO I'd be happy to open up a repository and work on this in the near future.

[fullcontrol-xyz]

Hi, your message got me working on it and I've just made the repo public today. There are some changes I still need to make to how the simulation technically runs from a conceptual point of view (not coding efficiency, etc.) so assume anything you do to it now may be entirely invalidated by future updates for the time being.

You can access the repo here:
https://github.com/FullControlXYZ/volco#readme

And there's a colab notebook here that works, but isn't polished yet:
https://colab.research.google.com/drive/19KmIh5iUVEQdWWmJfk-Wm9dZLUq4IDHV?usp=sharing

That colab shows some preliminary integration to fullcontrol, using gcode as a translation language between them. I need to solve some issues with volco requiring older versions of numpy and trimesh, but once that's solved, I'll directly implement volco into fullcontrol (likely as an optional dependency rather that duplication of code). So you'll be able to do something like fclab.transform(steps, '3d_model', fclab.ModelControls([volco setup stuff])

In the longer term, computational speed and also memory usage will be of interest... voxel models scale to the power 3 unfortunately, so get very big very quickly. However, in the short term, I think it's best to keep things as simple as possible and in python. The stl file size is often a big challenge anyway. I got one 800Mb in size from a few mins of a volco simulation, so it may be the case that output data format and visualization methods become a more important thing to optimise/develop than volco simulation speed.

Feel free to have a play around with the package. It's only a few mins of chatgpt help away from doing an FEA simulation. If you're doing research, please keep me in the loop and try to include me in paper co-authorship where directly appropriate, to make open-sourcing stuff continue to be appealing for me :)