[Enhancement] Extrusion multiplier

[tobychui]

Hi there!

Recently I try to move from CuraEngine to GoSlice on all my printers and find some under extrusion issues on one of my 3D printer. My printer has the following configuration Type: CoreXY Nozzle: 0.4mm Filament Diameter: 1.75mm Firmware: Repetier-Host

Currently I have to manually adjust the filament diameter to compensate for the under extrusion issues but this method is not ideal. May I ask for an additional slicing parameter called "--extrusion-muliplier" and allow mulitplication of extrusion rate? (e.g. 150 for 150%)

Thanks!

P.S. Attached with the top layer image taken under a microscope of 1.75 PLA filament with default filament diameter settings (1750, under extrusion) and manual adjusted filament diameter (1250, much better)

[aligator]

Hi!

it's very nice to see that someone actually uses GoSlice :-) But are you sure it works good enough for daily usage?

To the issue: I think its a very easy option to add. I will look into it.

[aligator]

Could you please test it?

https://github.com/aligator/GoSlice/releases/tag/v0.3.0

[tobychui]

Thanks for your quick fix :)))

GoSlice is much easier to use on Linux then CuraEngine and less picky to (broken) STL files compare to Slic3r. Specially with CuraEngine's complex parameters and config files.

I will do another set of testing this weekend. I will update you by then, thanks!

[aligator]

I did a test print today and noticed, that I applied the extrusion multiplier in a wrong way. Fixed it now: https://github.com/aligator/GoSlice/releases/tag/v0.3.1

[aligator]

Hi @tobychui did it work for you? Can I close this issue?

[tobychui]

Hi @tobychui did it work for you? Can I close this issue?

Hi, sorry for the delay as the GoSlice breaks my extruder during my test last month. The new extruder just arrived a few days ago and I will be testing them soon.

If you don't feel like having an opened issue, feel free to close it and I will open a new one when I encountered any issue. Thanks so much for your work!

[aligator]

sorry that it destroyed your extruder...

I will keep that issue open, just wanted to know the state of it.

[tobychui]

Hi! Here are some updates. I have tested the new version of GoSlice and I discover something interesting. Now it requires an extrusion multiplier of > 1 on all my 1.75 filament diameter with 0.4mm nozzle FDM printers. From my testing, some printers even need to set the multiplier to around 1.7 - 1.8 for a decent quality print.

Printing test of a cube capture under microscope, top layer, using RA20 3D Printer (Running Marlin firmware)

1.0x multiplier (100) It didn't stick to the platform due to under extrusion

1.2x multiplier (120)

1.4x multiplier (140)

1.7x multiplier (170)

1.8x multiplier (180)

I will try out the 1.9x - 2.3x range by this weekend. Hoping I can find a value that can deliver the best printing quality on all my 1.75 3D printers.

[aligator]

Hi, thanks for the testing. one possible thing would be that your leveling is slightly different than the last time. Because 100% should't make a difference to before. (If there isn't another bug... :-)

Do you think that this is only a problem for the first layer? If so we could introduce something like an InitialExtrusionMultiplier only for the first layer.

Also you may play around with the InitialLayerThickness.

Edit: on your photos it really looks like that it is wrong also on the upper layers. Next week I have time to do some tests on my own. Maybe I find something.

[aligator]

hi,

I did a test print today with these settings: (extrusion width because I use currently a 0.3 Nozzle)

~/bin/goslice --hot-end-temperature 225 --initial-hot-end-temperature 225 --bed-temperature 70 --initial-bed-temperature 70 --skirt-count 2 --extrusion-width 300 20mmCube.stl 

And it does not look like under extrusion on my printer. At least not on the top layer. The more inner top layers are maybe a little bit under extruded,Maybe because there it is bridging a bit? But I experience that with other slicers also.

The top layer looks perfect to me:

Anything else I could test?

[tobychui]

I am currently try to balance the extrusion multiplier between the top layer infills as well as middle layers infill. As I own both a 0.3mm nozzle machine as well as a 0.4mm nozzle machine, I tested GoSlice on both of them. This problem occurred on both machines (with different extruder design though). The situation can be best illustrated by the two photos below.

The first photo here show holes on the side surfaces (or middle layers) due to under extrusion.

So I try to increase the extrusion multiplier. In the next print, side surfaces (or middle layers) print perfectly fine but this time the top layer is under extrude as illustrate by the photo below

I wonder if there are some kind of logic / math error within the code where the extrusion multiplier applies on top / bottom layer is a bit difference than the middle / side surfaces.

For all my test I have done, I can observe the prints with given extrusion multiplier, only come out with an either the top layer is under extruded, or the side surface have holes due to under extrusion. I also replaced the nozzle with a new one just in case but it didn't help.

Updates: I also found issues for the wall not sticking to the body when printing circular hole on the edge of a printed parts. I believe this is related to path generation instead of infills. I might create a new issue later after I research a bit more.

[aligator]

Hi, thanks for the information. I would not be surprised if there is a rounding error somewhere, since I created the logic in a very "naive" way by trial and error because I am not that an expert with polygon geometry calculation. But we can try to Improve that.

While looking over the code where the extrusion gets set, I noticed that I maybe used the InitialLayerThickness for all layers because it gets set on the first layer: https://github.com/aligator/GoSlice/blob/d07f4bd9e55dbe8a1d4ad73abc82691c80a0b666/gcode/renderer/layer.go#L34 but only set to LayerThickness for the top layer... https://github.com/aligator/GoSlice/blob/d07f4bd9e55dbe8a1d4ad73abc82691c80a0b666/gcode/renderer/layer.go#L79

[aligator]

Here a testbuild which may fix that: https://github.com/aligator/GoSlice/releases/tag/v0.3.2-rc1

II did not test it yet, so be carefull :-)

By the way: currently you have to set the --Initial... values always, when changing the not-initial values so that they match.

Do you think it would be better to always use the not-initial values also for the initial values? Example:

currently:
--initial-layer-thickness 100 --layer-thickness 300 results in InitialLayerThickness 100 and LayerThickness 300
--layer-thickness 300 results in InitialLayerThickness 200 (from hardcoded default) and LayerThickness 300

better: --initial-layer-thickness 100 --layer-thickness 300 results in InitialLayerThickness 100 and LayerThickness 300
--layer-thickness 300 results in InitialLayerThickness 300 (from LayerThickness) and LayerThickness 300

That way you cannot accidentally forget to set the initial values when changing the normal ones.
What do you think?

Also would it help you to provide a (optional) config file? I think it would be easy to add that, because there is a go-lib called Viper which does this automatically and supports several different formats. Maybe config files separated by printer, printing and filament. Then it would be possible to do something like that:

goslice --cfg-printer=anetA8.yaml --cfg-print=normal.yaml --cfg-filament=PLA.yaml

Also it would be possible to generate such a config file:

goslice --cfg-printer=anetA8.yaml --cfg-print=normal.yaml --cfg-filament=PLA.yaml --save --InitialLayerThickness 100 --...

This would 1. load all configs, 2. overwrite the explicitely given values 3. save the configs again.

[tobychui]

Hi! Thanks for the update. That explains why it is so hard for me to balance the extrusion rate on the top layer and other layers below. I will test it out next week to see if the update fixed my issues.

That way you cannot accidentally forget to set the initial values when changing the normal ones. What do you think?

I have written a script (glue code) to automatically generate the required parameters for GoSlice based on a subset of those required parameters. So I don't need to manually enter each value each time I slice. To your suggestion on creating a config file, I think it won't really helps anyone because

1. If they know how to build & use GoSlice in command line mode, they probably know how to write a bash script to automate it. And for those who only know how to use programs with GUI, a config file won't help much on this issue.
2. Adding dependencies to the project is not a good idea as it will only make the binary grow even larger. On the other hand if you are focusing for developers, exposing abstractions as a go module might be a good starting point for developers who want to continue develop on your slicer (e.g. make a GUI for your slicer or integrate into their own projects)
3. One of the reason I switch from slic3r and CuraEngine to GoSlice is because of its ease of slicing without the need for machine dependent configuration files (the json files in CuraEngine for example). Switching to config file will make it less attractive for me.

Hope my ideas can get you some new insights on improving GoSlice : )

[aligator]

Thank you for your thoughts :-)

exposing abstractions as a go module

Interestingly, that's already possible. You could just copy this file https://github.com/aligator/GoSlice/blob/master/cmd/goslice/slicer.go into a new project and add custom slicing, modifier or gcode generators, etc. It's already built to be modular. The only thing I could improve here would be making the values of the GoSlice struct fully public. Then you could just reuse the "glue" logic from Process`.

To the config: basically it would allow a bit different workflow than you use. But it would not change anything for your workflow as the current way would still be valid and the cmdline option would remain the same. The benefit of it would be a more easy usage without any scripts like yours. Not everyone likes to write scripts if the program itself could already do the same. Still I agree on point 2. If dependencies can be avoided it is always better. Maybe it is a good Idea to just provide two binary types. One for simple, normal-user experience and one for a usage like you do it. I already thought of creating some simple web ui for it (why web? because I couldn't find any good desktop ui framework I like, yet) It would be very easy to do as a 2nd project like you suggested.

Point 3 is also valid, the config would only be an optional addition to persist often used configurations. It would not be a switch :-)

Anyway thanks for your input :-)

[tobychui]

Hi @aligator , I just pulled the new updates from branch #38-wrong-extrusion and everything works perfectly. Both the side layers and top / bottom layers are correctly filled and no gaps appears between layers anymore. Moreover, now I can set all my machine's extrusion multiplier to 1x (100) as the updates seems to magically fixed some extrusion rate issues on different branded extruders.

0.3mm layer height

0.2mm layer height

top layer

I have tested with a few objects other than cubes and they show similar / better results than slic3r which is a great start for this amazing slicer. Thin walls are still not printing that great but I guess I will leave it to a new issue after a bit more testing. Thanks so much for your work and I will be looking forward to your future updates : )))

(I think we can close this issue now?)

[aligator]

Very nice :-) Thanks for testing.