Min layer time enforcement uses poor estimate

[richfelker]

The slowdown to enforce min layer time is performed using computeNaiveTimeEstimates, which disregards acceleration profile and assumes all moves take place at their nominal speed. For layers where none of the moves are significantly acceleration-limited, this of course doesn't matter, and for layers where all of the moves are severely acceleration-limited, it (perhaps surprisingly) also doesn't matter, because reducing their nominal/cruist speed actually does not affect the time they take (since they never reach cruise). But for layers that have some long straight moves that are not acceleration-limited and can take place at high speed, but also some small details, the "naive" estimate can cause the layer to be severely slowed down even when the actual time needed was already significantly longer than the requested min layer time due to time spent on the details.

Aside from making prints slow, this causes several other problems. When "lift head" is used, the dwell will be unnecessarily long, and the lift may even take place when it's not needed at all, causing unnecessary oozing. And some materials (e.g. BPET/HTPET) can crystalize in the hotend if printed too slowly, which can cause clogs depending on the hotend and extruder capabilities.

Reading ExtruderPlan::processFanSpeedAndMinimalLayerTime, it looks like this also affects choice of fan speed for the layer, and perhaps other things too, in adverse ways. This function should probably be changed to use the existing accurate time estimation code that's used for the final print, which takes acceleration profile (including jerk) into account.

[ky438]

not sure if talking to ultimaker or /dev/null :crying_cat_face:

[rburema]

(For the benefit of @ky438 I'll repeat that we're sorry that it took this incredibly long to get back on the engine tickets. That was not supposed to happen. I think @richfelker 's already had to read that apology for half of the other messages I wrote, so I've started leaving it out.)

In any case, we've worked on fixing the related #1203, which resulted in #1742 -- so now we can probably tackle this problem -- tagging @rijkvanmanen as well. (Devs, see related internal tickets CURA-7271 CURA-9778 PP-71)

[rijkvanmanen]

Thank you for the FR @richfelker. And I agree with your theory, but I expect the deviations in the estimation to be small.

To be sure I decided to check the difference between the naiveTimeEstimater and the more advanced time estimator used for the final print time for both a cone and a star:

And indeed the deviations from dependent on the shape of the object, but the deviations are clearly <10%. So, I don't consider this a significant problem and propose to defer this feature request.

BTW: the lift head time estimator is off: #1630

[ky438]

Maybe this will clarify things:

for layers that have some long straight moves that are not acceleration-limited and can take place at high speed, but also some small details, the "naive" estimate can cause the layer to be severely slowed down even when the actual time needed was already significantly longer than the requested min layer time due to time spent on the details.

[rijkvanmanen]

@ky438 if you provide a cura project file where you expect severe deviation in time estimation from the naive time estimator and the real time, I will check the difference to see how big the deviation is.

[ky438]

@rijkvanmanen - I don't have anything on hand at the moment (having been burned by this in the past) - perhaps @richfelker has something he can send :thinking:

[richfelker]

Try this file: badest.stl.txt

Slice it with something like 400 mm/s and some normal accel, e.g. 500-2000 mm/s², one wall no infill no tops/bottoms. First with min layer time of 0. Check the actual layer time. Then, set min layer time to the actual layer time and reslice. The actual layer time should jump a lot higher than the min layer time. With my settings it went from 2.7s to 3.8s. I didn't spend a lot of time optimizing this test case to be bad. I'm sure you can do a lot worse if you try. It's just a matter of having one stretch that can achieve a high speed and one section that's completely acceleration-bound.

[rijkvanmanen]

Thanks @richfelker for sharing this case. I was also able to create some test cases where the naive time estimator was >25% off. But it requires very specific geometries and low speed to acceleration ratios.

I will leave the priority of this FR to @rburema

[richfelker]

Thanks @richfelker for sharing this case. I was also able to create some test cases where the naive time estimator was >25% off. But it requires very specific geometries and low speed to acceleration ratios.

I think you mean very high speed to acceleration ratios. With very low, the naive estimate of all motion as taking space at the nominal speed is very accurate.

While I have hit real-world examples comparable to my test case here, I think a more common case I've hit is with multiple accelerations. I use low accel for outer wall to ensure perfect surface quality without ringing, but extremely high acceleration for everything else. A common case is for the outer wall of small layers to already, by itself, exceed the min layer time, but because the naive estimate says it should be very fast, the inner walls and infill get severely slowed down.