7
$\begingroup$

I'm currently in the process of fine-tuning my cheap CTC i3 clone. I'm using Cura 3.1 for slicing.

After calibrating the extruder steps, I wanted to optimize the line width and flow compensation parameters. I am using a 0.4 mm nozzle and therefore set the line width parameter to 0.4 mm in Cura. I then printed a cube with 0% infill, 1 wall line and no top layers (basically an open cube with 4 bottom layers). The wall width I measured on the printed result is 0.52 mm. To correct for the difference I set the flow compensation to 80% and repeated the print. The wall width I got from this was 0.45 mm, which is much better than before. There is only one problem: the parallel lines in the four bottom layers do not touch, so the print is not watertight. Up to now I assumed that Cura would calculate the distance between the lines from the line width setting. So with 0.45 mm lines and line width set to 0.4 mm there should even be some overlap.

Why am I seeing this effect? Am I getting something fundamentally wrong here?

Improve this question
$\endgroup$
1
  • $\begingroup$ Did you get to the bottom of this? I'm having the same issues and I have your same questions. :D $\endgroup$
    – Ivan Carosati
    Apr 7, 2019 at 15:53

3 Answers 3

Reset to default
1
$\begingroup$

That is very bizarre. Since GCODE describe each movement of the printing head (so, the printer does not get to decide anything in terms of printing strategy, it just executes), I can only see three possibilities that would explain what's going on.

The print is being scaled up at printer level. This could for example be due to your firmware having your steppers improperly calibrated and moving them too much for a given unit of measure (say you say 1mm, they move 1.5mm instead). This is easy to check: if this is the case, your cube will be scaled up (so - using the example above - if your cube is 10x10x10 it will come out 15x15x15).

You are printing with a raft. Then there is no problem with your set-up, the first layer(s) of a raft are not solid, but intentionally "grated". Check your settings to verify.

Cura is producing the "wrong" gcode. This could be really wrong (as in "you found a bug", in which case you should report it on their github), or just look wrong (as in "you found a weird combination of setting producing that gcode", in which case you should reset the settings to their default and see the problem disappear). Either way, if the gcode is "wrong", you should notice the gaps in the gcode preview mode in Cura.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Hm. I can rule out #1 (the steps/mm are calibrated) and #2. To check #3, I sliced the same object in slic3r with settings comparable to those in Cura. The print came out with 0.40 mm walls (nice), but also here, the lines in the bottom layers do not touch... $\endgroup$
    – Sven Rusch
    Feb 20, 2018 at 9:16
  • $\begingroup$ @SvenFestersen - so you are positive the dimension of the final cube are the same of the model? If that's the case, I'm puzzled. $\endgroup$
    – mac
    Feb 20, 2018 at 16:24
  • $\begingroup$ yes, the edges of the cube (designed 25x25x25 mm) are 24.9+/-0.05 mm. Even more interesting is the fact that i was able to pull one line from the bottom layer and measure its width: 0.45 mm. The next thing I'm going to try is reducing the first layer height a bit to spread the first layer lines. $\endgroup$
    – Sven Rusch
    Feb 21, 2018 at 9:53
1
$\begingroup$

It's impossible to get a true measure with calipers because of the bumps from layer lines. The printer/slicer is working on an average of the peaks and troughs but the calipers only measures the peaks. Thus, after measuring and compensating, you told it to under-extrude and it did.

Improve this answer
$\endgroup$
2
  • $\begingroup$ This is probably the closest answer. Your measurement will not be the width of the line, but the distance between the greatest outliers in either direction. You are getting 30 microns of deviation in each direction, which is not unheard of. When you pulled one line away and measured that, you eliminated the deviation. $\endgroup$
    – GDorn
    Apr 24, 2020 at 2:33
  • $\begingroup$ Yes, I suspect OP has significant Z-wobble or other issues making the line position deviation a significant factor in the effective line width. You should never need a flow correction as severe as -20% to get correct width, assuming the extrusion length was already calibrated. Typically it's more like -5%. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Apr 11, 2022 at 13:55
0
$\begingroup$

Cura does not adjust line width to account for lower flow (aka extrusion multiplier), they are independent settings. Therefore, if you have to reduce extrusion to get the correct wall thickness, then as you said, the lines may not be close enough together to fuse properly and you'll have a weak part. Try reducing the line width. First though, I would take the below troubleshooting steps:

  1. Calibrate e-steps in firmware
  2. Calibrate the actual diameter of the filament you're using
  3. Calibrate flow for the correct wall thickness
  4. Adjust line width in Cura if needed to get proper fusing

Lastly you might want to check for a partial nozzle clog which can cause under-extrusion, though that is usually not consistent

Improve this answer
$\endgroup$
2
  • $\begingroup$ I'm not clear what you're claiming they're doing wrong. Lines requested to have 0.4 mm width should be (and are) printed with their centers having exactly 0.4 mm between them, independent of flow setting. Changing flow should not (and does not) change anything about how the lines are positioned. $\endgroup$
    – R.. GitHub STOP HELPING ICE
    Apr 11, 2022 at 13:53
  • $\begingroup$ True, it's not really a problem, the functionality just works differently than expected. It makes sense that flow could be set independently from line width. I have edited my response accordingly $\endgroup$
    – Samwise Ganges
    Apr 18, 2022 at 18:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .