High speeds are getting clamped / overflowed

[nicolasnoble]

Here is the gist of the problem: when specifying speeds that are too high, Slic3r will get them quite wrong. Here is an example, generated from a cube file.

Default speed, first layer with a 50% speed:

Second layer with the same default speed:

And we can see that it is properly about twice as fast as the first layer.

Now if I quadruple every single speed setting - except the travel speed one; the first layer indeed has quadrupled:

But the next layers has numbers that quite won't match that; in fact, the next layer is slower than the first, which is quite contradictory with the settings:

It looks like the speed stayed the same, and got clamped for some reason that I quite can't explain.

I may be doing something wrong with my settings, for which I'd be grateful to get an explanation, but at the same time, it feels wrong that two layers that are supposed to be of different speed are in fact getting swapped.

[ledvinap]

Could you post exported settings and model? Most probably this problem is caused by cooling feature enabled - print speed is lowered to maintain minimum layer time.

[nicolasnoble]

You are correct: the "inner layers" slowdown was caused by the auto cooling. Here are the settings with auto-cooling on: https://www.dropbox.com/s/n8iyuktw3b06xz0/slic3r-config.ini

However, the first layer and the top layers were ignoring this. Meaning that if you slice something using these settings, the first layer will be super fast, then all of the inside layers will be capped by the auto-cooling, and then the 4 top layers will be super fast again. Meaning they weren't affected by the auto-cooling. I guess we can change the bug description to specify this :-)

[ledvinap]

It's still impossible to reproduce this without model ... From attached ini there are 4 top solid layers. Solid layer takes longer to fill than 20% infill, so layer time slowdown may not be triggered ...

[nicolasnoble]

Sorry about that: https://www.dropbox.com/s/2jmky4y9ew9eud2/cube.stl

[ledvinap]

All layers except layer 246 take over 30s (gcode.ws), this is expected behavior.

Layer 246 is does take 19s. This is first solid layer above infill. Solid infill over sparse one is printed using bridge setting and bridge speed is not affected by minimum layer time (this is correct behavior). Only problem here is that slowdown is calculated over entire layer and does not consider bridges being printed at full speed. This could be improved/fixed.

In my opinion layer 0 should ignore minimum layer time and use set speed (layer is cooled by print bed and user can control first layer speed if necessary. Adhesion is much more important here). This is not currently implemented and is probably design flaw.

[alranel]

@ledvinap, thanks for helping here.

Bridge time computation should be fixed, yeah. Regarding first layer, it's cooled by print bed only if you have a cold print bed :-) Also, cooling should only affect first layer in terms of slowing it down. So the actual speed will always be equal or lower than the configured First layer speed. This should not make adhesion worse in any case. Or am I missing to consider some situation where printing too slowly would make adhesion worse?

[ledvinap]

Not sure about adhesion, but here are some aspects to consider:

• mass of deposited material for first layer is quite negligible compared to mass of bed (0.4mm layer over 2mm glass is probably extreme). Heating of bed caused by deposited material should be quite small.
• the layer is very thin, so it should cool to bed temperature very quickly (heated bed or not)
• heat conducted from nozzle to bed may be larger than heat transferred with print material. This is already exploited y lowering first layer speed. Printing slowly could result in larger local bed temperature for small contact area models.
• user can tune first layer speed if required

In my opinion using first layer speed and ignoring cool time will produce more consistent results. It's also quite easy to tune first layer print speed to extend first layer time, but there is no way around minimum time (that is necessary in other layers)

There may even be problems with materials like taulman 618 with too much adhesion:

Precision Bond = Machinable Garolite (LE) McMaster Carr PN 8474K141, 8474K151, 8474K161, 8474K171 Warning: Keep surface area to the Garolite at a minimum or you will break your part trying to remove it.

[alranel]

See, I don't like to change such an important thing without a strong reason demonstrated by a test case. I learned one thing so far: unexpected behavior is perceived by users as a bug. This not only leads to many bogus reports, but also means user experience is worse because the proposed pattern (i.e. tune First layer speed) is uncomfortable. User should not be forced to tweak that option according to the footprint of each print. Users expect print speed to honor the cooling slowdown without exceptions.

A hotter and/or slower first layer is usually a good thing. I can't think of a situation where a slower speed would have a bad impact on anything, except for printing time, so we're on the safe side...

Of course I'm open if there's strong general consensus towards such a change, but so far nobody raised an actual problem with the current behavior. @pixelxeno's confusion regarding first layer is caused by Slic3r not exposing its estimated layer print times, thus not making clear what slowdown factor (if any) was applied to each layer. If first layer is printed at 50% speed, it's very likely to be longer than the slowdown threshold unlike the following layers which are stretched to fix the configured minimum time.

[alranel]

Maybe we should write the slowdown factor in a comment at the beginning of each layer in G-code. The reason I didn't do it is that our time estimations are wrong (like any time estimations implemented so far) and I don't like to expose them...

[ledvinap]

Yes, you are right. Slowing down all layers is option with least surprise for user. The comments could only state slowdown factor (that is accurate) and maybe requested layer time. It's not necessary to expose time estimate.