Wrong printing time estimation.

[vovodroid]

Description of the bug

I payed attention that PS printing time estimation is about 30-50% larger than real printing takes. I have all limits emitted to G-code

Printer is Biqu B1 SE with flashed latest Marlin (bugfix-2.1.x). I would understand if real time were more than estimated due to printer limits, but not opposite.

Project file & How to reproduce

Slice, print, measure time.

Checklist of files included above

• [ ] Project file
• [ ] Screenshot

Version of PrusaSlicer

Version 2.7.0-beta1

Operating system

Win10x64

Printer model

Biqu B1 SE

[neophyl]

Question for you, you mention your printer isn't running Marlin, so even though the M2xx codes are set to be in the output gcode file does your printer actually support them and use them ?

[vovodroid]

you mention your printer isn't running Marlin

It does run Marlin 2.1.x, probably my definition wasn't clear, I'll fix it. And it supports M73 command.

[neophyl]

I did a bit of research earlier and found that the biqu printers are based on Marlin, unfortunately they don’t appear to be open source so it’s impossible to tell if they use the m2xx commands. It all depends on if they are implemented in their build.

In the past when I had a creality printer which had a similar problem, the only thing was to read back the actual limits from the printer and enter them into PRUSA slicer to ‘accurize’ the time estimates.

[vovodroid]

biqu printers are based on Marlin, unfortunately they don’t appear to be open source

I don't use Biqu firmware, but built original Marlin.

[vovodroid]

Anyway real printing time has nothing to do with M73.

[lukasmatena]

@vovodroid can you post a 3mf? Thanks.

[vovodroid]

@lukasmatena actually it happens with any print, but here are two latest examples.

Very big print. Estimated time about 14h, real time about 10h: Bigplate.zip

Small print. Estimated time 1:24h, real time 1:05: Brakets.zip

[rtyr]

Is your Marlin FW configured to use classic jerk or junction deviation? Our time estimator supports only classic jerks and you have set jerks to quite unusual value (0). If I set jerks to some usual values, the estimate is around 10h. Also I am not sure Marlin works properly with zero jerks (early Marlin versions certainly did not).

[vovodroid]

classic jerk or junction deviation?

Junction deviation I guess:

//#define CLASSIC_JERK
#define DEFAULT_EJERK    5.0  // May be used by Linear Advance

#if DISABLED(CLASSIC_JERK)
  #define JUNCTION_DEVIATION_MM 0.01 // (mm) Distance from real junction edge
  #define JD_HANDLE_SMALL_SEGMENTS    // Use curvature estimation instead of just the junction angle
                                      // for small segments (< 1mm) with large junction angles (> 135°).
#endif
#define S_CURVE_ACCELERATION

If I set jerks to some usual values, the estimate is around 10h.

Indeed, great! So I can set it to larger value to match real time, printer will ignore M205 with jerk values.

Anyway it would be nice to support junction deviation as well.

[rtyr]

Indeed, great! So I can set it to larger value to match real time, printer will ignore M205 with jerk values.

Yes, it should give you quite accurate estimates.

Anyway it would be nice to support junction deviation as well.

There is already FR for it https://github.com/prusa3d/PrusaSlicer/issues/2115.

So I guess we can close this issue?

[vovodroid]

I guess we can close this issue?

Yes, I'm closing it.

[vovodroid]

It's still not correct with classic Jerk. I built Marlin with #define CLASSIC_JERK, and set following in slicer:

Nevertheless in another project real time is about 3:30 vs 3:10 estimated. Could it be related to #define S_CURVE_ACCELERATION, as it slows down acceleration/deceleration?

With jerk decreased to 4 estimated time is close to real.

Also "Emit to G code" and "Use for estimate" produce slightly different results.

[rtyr]

It can be affected for example by linear advance. FW slows down the print automatically (decreases acceleration) to not exceed extruder jerk. This is not emulated by slicer.

You can test this either by disabling linear advance (M900 K0 in filament custom g-code) or by increasing extruder jerk a little bit (you would have to emit it to the g-code or change it directly in the fw).

[rtyr]

S_CURVE_ACCELERATION should not be enabled together with enabled linear advance (I believe this combination is not yet supported by Marlin properly)

[vovodroid]

S_CURVE_ACCELERATION should not be enabled together with enabled linear advance (I believe this combination is not yet supported by Marlin properly)

It was experimental, but now it's standard in bugfix-2.1.x branch.

[vovodroid]

linear advance. FW slows down the print automatically (decreases acceleration) to not exceed extruder jerk.

Doesn't LA deal with filament and pressure properties?

[rtyr]

Doesn't LA deal with filament and pressure properties?

It requires quite violent extruder movements. Since linear advance 1.5 (current), the Marlin firmware logic automatically limits XY print acceleration during the print to never exceed maximum extruder jerk (to prevent skipped steps like it could happen with linear advance 1.0). This can be quite big issue especially on bowden printers, where big K values are usually used (It would need very high extruder jerk values to not slow down the print).

[rtyr]

From LA1.5 changelog:

Special notes for v1.5 Changelog

• K is now a meaningful value with the unit [mm of filament compression needed per 1mm/s extrusion speed] or [mm/mm/s].
• Load inside stepper ISR reduced as no calculations are needed there any more. Instead, the extruder runs at a fixed speed offset during pressure adjustment. Therefore this version runs faster.
• LIN_ADVANCE now respects hardware limitations set in Configuration.h, namely extruder jerk. If the pressure corrections require faster adjustments than allowed by extruder jerk limit, the acceleration for this print move is limited to a value which allows to use extruder jerk speed as the upper limit.
• The pressure adjustment moves don’t lead to a rattling extruder as it was in v1.0: as the extruder is now running at a smooth speed instead of jerking between multiples of extruder print speed.
• This smooth extruder operation and respecting of jerk limits ensures no extruder steps are skipped.

[vovodroid]

I have direct extruder and LA 0.07-0.08. Which E-jerk value would you suggest?

And what do you think about S-curve effect?

[rtyr]

It really depends on what your extruder can really handle without skipped steps and without excessive noise. It will be probably something like 7-10 to prevent any slowdown. S-Curve may also play some role, even though I think it will be smaller than LA. We tried s-curve+LA combination back at the time and LA did not work properly. I know it is now possible to build Marlin with such combination but as far as I know it is still not without issues.

[vovodroid]

It really depends on what your extruder can really handle without skipped steps and without excessive noise.

It can, I set it to 10 just now, will check effect.

I know it is now possible to build Marlin with such combination but as far as I know it is still not without issues.

At least it is not consider experimental for year https://github.com/MarlinFirmware/Marlin/pull/25238

[vovodroid]

Well, I changed E jerk from 5 to 10, it didn't affect printing time with LA 0.07

To summarize the case:

Estimation with jerk 8 was 3:10, actual printing 3:30 (with two objects it was 40 minutes excess). To get correct estimation I needed to set jerk to 4.

With real jerk 10 slicer jerk 5 gives correct estimation. Object in question is small (about 65*20mm) and tall (480 layers), non soild with complex geometry, so it demands many small movements.

Increasing E jerk from 5 to 10 didn't affect real print time.

Open question: while "Emit to G code" and "Use for estimate" produce slightly different results (emit estimates 15 minutes less for 10 hours print)?

[vovodroid]

Another finding - when "Use firmware retraction" is enabled, time calculation doesn't take it into account, as if retraction were zero.

[rtyr]

PrusaSlicer does not have any info about FW retractions, therefore it cannot estimate time for it. FW retractions are also very rarely used afaik.

Anyway, in general PrusaSlicer takes the generated g-code and then emulates the firmware (except things like linear advance, junction deviation etc.). As far as "emit to g-code" vs "use for estimate" difference, hard to say from top of my head, @enricoturri1966 may have better info regarding this (I don't see any time difference when I tried it).

[vovodroid]

PrusaSlicer does not have any info about FW retractions, therefore it cannot estimate time for it.

Could it use the same approach as for "use for estimate"?

[enricoturri1966]

As far as I know, the only difference between "emit to g-code" and "use for estimate" options is that, when using the first one, lines as the following are added at the beginning of the exported gcode:

M201 X2500 Y2500 Z400 E5000 ; sets maximum accelerations, mm/sec^2
M203 X180 Y180 Z12 E80 ; sets maximum feedrates, mm / sec
M204 P2000 R1250 T2500 ; sets acceleration (P, T) and retract acceleration (R), mm/sec^2
M205 X8.00 Y8.00 Z2.00 E10.00 ; sets the jerk limits, mm/sec
M205 S0 T0 ; sets the minimum extruding and travel feed rate, mm/sec

From what I see, the estimated time does not depend on the selected option.

[vovodroid]

From what I see, the estimated time does not depend on the selected option.

For simple projects it's negligible, but for big complicated models you see this:

Emit:

Estimate:

Not a big deal, but nevertheless it's strange.

time-box.zip

[vovodroid]

you have set jerks to quite unusual value (0)

I payed attention, that not especially zero, but just small values (like 1-3) cause to underestimation printing time.