G-Code optimiser

I have noticed that Slic3r does not optimise very well the order of extrusion paths it takes to minimise print time.
For example, the order in which extrusion paths are made within the same layer can be rearranged to minimise the travel distance between these extrusion paths.
Some initial inspections of the G-Code produced by Slic3r reveal that travel time alone between extrusion paths can take around 15% of the total print time, depending on the model being printed.
This problem is a generalisation of the Travelling Salesman Problem (TSP), which is NP-Hard, so it is understandable that Slic3r makes little attempt to optimise this.
I would assume that printing infill before perimeters or vice-versa makes little difference to the quality of the print, and extrustion paths in the same layer can be re-ordered in any way, as long as the extrusion paths themselves are in the same position and extruder retraction and Z-lift is performed between them if necessary.
Initial experiments with some software I have written to solve this have shown around a 10% reduction in my print time.
The software simply takes in a G-Code file, optimises it and produces a new output G-Code file.
The software needs much more development and testing before a release, it is still very experimental but has shown promising results.

My questions are:
Is there any other software like this which attempts to solve or optimise TSP for 3d print paths?
What would be the community interest if I were to further develop and release this software? Would you use it?

Hi KarlB.

I wonder that the theme has not the attention that it need.

I look since years to the different slicing programs (Slic3r ; Slic3r -Prusa; KISS ; Simplify3D ; Cura ; Craftware; …)
But I observe no ongoing “intelligence”.

For me the theme is not only a time problem…it is an high priority criteria if you print functional parts.

So for example it is not possible to print larger “Frontpanels” with rectangle or round spare outs.
After long unnecessary travel there is missing the firs 2-5 mm for the new track, and so the surface is ugly or maleformed. (Holes for example)

If the slicing programming teams has not the interest here, a G-Code optimizing program is high interesting.

JoRo

Thanks for the reply Joro.
Hopefully my software should be able to solve the problem you have with missing extrusion for the first few mm of the track by minimising travel moves.

You're right that the main slicing programs don't appear to have any intelligence in minimising travel moves. They will go back and forth over the bed laying down paths in all different places when the moves could have been re ordered to be more efficient.

I've also noticed where the end of one extrusion path is very close to the start of the next, and the travel is <1mm between them for example, the deceleration and acceleration performed is unnecessary since they are so close. I've been able to merge the two paths into one in this case so there is no slowdown. This commonly happens when printing skirt loops on the first layer or when it is printing perimeters around holes.

You're right that the problem is not only time, it would also lower electricity costs and wear on mechanical parts of the printer.

At the moment I still need to perform a lot more testing to ensure there are no bugs that would mess up the print, but progress is going well.

Hi.
The reaction here is the reason while I feel somtimes like a alien.
Nobody(or to less) has an interest.

Possible most printer's prints artwork like vases or so (:-)
Often I read "use raft" ....but raft is an absulute nogo for technical parts and/or visible surfaces.

Maybe to use a hachtag like "Z-Probing" will help to bring this theme to more attention. (:-)

Possible it was helpfull to optimize only the first layer in the way that all element are print as
continuos line. (Sure, I speak not from a 100% filled surface....in such you see any small problem.)

My way for visible surfaces is to work for the first layer only with "Grid" 33% filling or so.
Than for the above layers (backside) closed surfaces.
So I get a closed board (as wall for a box for example) with an surface who the eye see not every small mess.


Greeting all Aliens
JoRo

I've written many unit tests over the last week in my software which helped me fix a lot of bugs. It is now running much more stable and seems to output correct G-Code for the files I've tested.
I should be ready for beta testers in a couple of weeks or so.
The next thing I need to do is to get it to read it's settings from a config file so that things can be user configurable.

I don't like how slic3r has only the option for bed temperature at first layer, then bed temperature for all other layers, it is not very flexible. So I have added the functionality into my software to be able to give bed temperature for first N layers, then after this reduce the bed temperature by X amount until a minimum is reached. For example, I like to print ABS with my bed temp at 100c for the first 10 layers, after 10 layers it is gradually reduced by 5c per layer until it reaches 40c, and keeps it at that for the rest of the print.
Often it is not enough to prevent curling if you only keep the bed hot for the first layer, it needs to be kept hot for the first 10 layers or so, so that there is a bit more rigidity provided, and then you can start to reduce the bed temp gradually.

Hi KarlB.
I try to add the file to the PM but possible it fails...
So here the GCode and the STL.
Possible have other Aliens also an Interest for the Problem.
The goal is to print the panel with the visible surface on the build plate without fails an scratches.

JoRo

"I would assume that printing infill before perimeters or vice-versa makes little difference to the quality of the print"

you would be wrong in this assumption.

It matters a lot.

Why is that the case?

from slicer manual

"Infill before perimeters - Reverses the order in which the layer is printed. Usually the perimeter is laid down initially, followed by the infill, and this is usually the preferable as the perimeter acts as a wall containing the infill."

I also find that if you do infill first you can get bumps on the surface as the infill pushes against the perimeter

If you only use 1 Perimeter it matters a lot. IMHO if you use 2 or 3 perimeter it doesn't matter a lot.

I'm very interested in your optimizations. But why are you implementing a post-processor and not a optimized version of e.g. slic3r?

Hi.

Three Remarks from me:

1.Printing the infill before the outline is not the solution (for me) .
Not all slicing programs have that feature.
The sort order is also not intelligent.

2. The count off perimenter is not the solution for the described problem.

3. The idea foe G-Code optimization is very good.
There are other slicing programs nearby slic3r....

JoRo

I'm sure there are more things possible to optimize in generating the g-code than in optimize the generated g-code.
He wrote that his optimization are for slic3r generated g-code. Maybe it optimizes other g-code as well, but who knows

Your problem with missing 2-5 mm track is more a problem with your extruder retract settings.

Hi Rossini.
No, it is not a retract problem.
The missing material after a long jump occurs also with complete deactivated retract.

Idea for KarlB:
I think for the "visible surface problem" it would enough to optimize the really first layer in G-Code and
let the rest as the slicing prog. does.
(The generatet "A" or "E" values have to export as "relative", so the 2nd layer "A" ;"E" value can start by zero.)

JoRo