"Estimated printing time" incorrect: printing time is large negative number

[ruedli]

Version

2.2.52

Operating system type + version

Windows 10

3D printer brand / version + firmware version (if known)

Prusa i3 MK3s / MMU2S

Behavior

When slicing the printing estimates are incorreect. Also the esitmates per layer (as displayed in Octoprint) are wrong.

I am using a MMU2 profile, and attached the project file with settings. All my MMU2 prints show this. I am using height modifiers to specify extruder transitions, this could be contributing.

In the standard Prusa Slicer, the problem does not occur.

Is this a new feature request?

Project File (.3MF) where problem occurs

cover_lcd_skr.zip

[codingcatgirl]

This happens in PrusaSlicer too.
For me it always seemed to have something to do with brim size, but in general it seemed to be almost completely unreproducible sometimes.

[ruedli]

I could bring the same objects / same project in again, and they sliced without problems now... Very strange with its reproduceability... Repairing the non-manifold element had no influene. My assumption for now is that once the slicer comes in this state, it stays. When it happens again,I shall save the project, exit and open the project and see if this resolves it.

[supermerill]

I think it's random.
maybe next prusa release will correct it.

[robthide37]

yes it is you can change the infill when it happens and it will self correct. i think it happens more when background slicing is on and it tries to recycle some calcluations. you would know better but seems some reslices are way faster so something caches and when you change a setting it messes things up with the time estimation

[Alonso3D]

Ive had this issue as well. For me it would happen when using the wipe tower. See 3rd issue within #276,

[vertigo235]

Same issue here, didn't realize it was in Prusa Slicer too (ditched that pony a while back!)

[Alonso3D]

I'll add that after purging dual nozzles in the beginning, the gcode tried to move the nozzle to -X (rather huge number) causing the printer to shutdown. I had to manually adjust the gcode to something sane like X 50 and it worked fine. I beleive the massive move is what is contributing to the crazy time estimates

[stelgenhof]

The infamous -2^31 :) Likely an overflow condition or missing value somewhere.

[supermerill]

I've added a check, that print a message on the console and retry to compute the printing time.

[LuckyTurtleDev]

I can confirm that the issue still exist in SuperSlicer 2.2.53.3.
Sometimes the number is not negative, but very large (1196d 22h 2m print time).
The negative numbers looks like an overflow.

[LuckyTurtleDev]

The time calculation seem to be correct at the latest version (de57391). I was not able to reproduce the issue with this version.

[LuckyTurtleDev]

I get this issues in Superslicer 2.2.54.2 again.

[codingcatgirl]

Oh, is this gone? That would be awesome news! Haven't seen it in a while.