slicer printing time vs real printing time

[garethky]

@T3P3Tony Diffing the files is an excellent suggestion, thank you!

The two profiles have differing retract lengths distances. But unfortunately this was in the favor of the Duet printer, it is set to 0.4mm and the MK3S is set to 1.4mm. Other than that the two slices make the same moves with the same speeds.

I set up a profile that the two printers could share so they can slice under exactly the same settings. The only diff I can find is this:

For some perimeters, the MK3S gets a slightly higher feed rate. I actually can't find the setting that controls that?

But I can force 10mm/s higher perimeter speeds on the Duet machine to compensate and run the simulation. Its still about the same amount slower, as reported above, in my simulations.

[garethky]

I tried slicing simpler shapes.

A 100mm cube with no infill, printed square and at 45 degrees to the printers axes, no top or bottom layers. Both simulations are within 2 minutes of the slicer's predictions.

100mm diameter cylinder, 100mm tall, no infill, no top or bottom layers. Seems the problem is with curves:

First of all, extruder and z settings are not the root cause here. There are just as many retractions in the square test so that should have impacted both shapes equally. This is about X/Y moves. That's the same conclusion I came to in previous tests.

Second the variance in layer time here is bizarre. Min layer time is 19s and max layer time (not first layer!) is 34s. All the layers are basically the same. There are no travel moves.

So what, if anything, can fix this?

• Doubling speeds to 360mm/s: no impact
• Doubling accelerations to 4000mm/s: no impact
• Raising jerk by 10x to 20mm/s: no impact
• Raising jerk to 100mm/s: no impact
• 10x speed, accel and jerk on X,Y,Z & E: no impact

Cool! So its not my config or

The gcode asks for a specific speed and acceleration that is well within the printers configured limits. The firmware thinks it achieved those requested speeds and accelerations. But the print time is almost an hour longer than the slicer's estimate.

Can we call this a bug now?

[T3P3Tony]

do you have a min layer time set in the "cooling" settings (that may be different)?

[Phaedrux]

Not sure if you've tested this yet, but can you try using firmware retraction instead to see if it changes the outcome?

[garethky]

@T3P3Tony said in slicer printing time vs real printing time:

do you have a min layer time set in the "cooling" settings (that may be different)?

Yes, but even so, the slicer would include that in its estimate, it knows what it did. But I'm going to disable it for this test because its irrelevant.

@Phaedrux said in slicer printing time vs real printing time:

Not sure if you've tested this yet, but can you try using firmware retraction instead to see if it changes the outcome?

I can tell you from prior experience it wont but I will go one better, lets eliminate all retracts from the test print. We can do that with spiral vase mode. No retracts the whole way up, no travel moves other pauses, just plain circles. This is simple enough that we can make an estimate of print time based on the radius (50mm), height (100mm) and print speed of 35mm/s:

2π * 50 = 314.2 circumference
100mm / 0.2 = 500 layers
500 * 314.2 = 160600 mm traveled
160600 / 35mm/s = 1h 16m approximately

The slicers estimate is 1 hour 24 minutes which is pretty close to our estimate. You can also see see the slicer is emitting moves for a 35mm/s speed (this is the configured outer perimeter speed):

Then simulate it on the Duet:

We can then estimate the Duets actual achieved speed as 160600 / 1h 46m 58s = 25.02mm/s
That's a loss of 10mm/s from the desired speed.

And just out of curiosity, what happens if the outer wall speed were a lot faster? Say 100mm/s? Is the effect linear or constant?

This is where my Jaw hit the floor. Its not a constant effect, going faster makes it worse:

So that's 160600 / 1h 22m 11s = 32.5mm/s

[garethky]

Oh and here is a cube for comparison, same vase mode, 100mm/s perimeters etc:

The printer is happy to do 100mm/s and take square corners that fast. Its not a printer settings issue. My computed speed estimate for that is 88.6mm/s.

[garethky]

I tried printing the 100mm/s test and the printer prints at the requested speed.

Also note that the time for individual layers in perfectly consistent as expected. Its the simulation that is wrong in this case.

My guess is my real speed issue is related to Z or E as I originally suspected but I'm unable to see that from the simulation.

[milan.baca]

garethky - do you have solved this issue?

[garethky]

No, I gave up the investigation. Something about the simulation isn't accurate. Something about the real print time isn't right either.

[Phaedrux]

We've been investigating and I think we've identified something but I'm not sure of the specifics.

[Schild0r]

@Phaedrux has anything been done in the firmware regarding the discrepancy between slicer predicted and actual print times?
I am using the current version of Prusaslicer and RRF 3.5.1 and still see a significant difference.
Prusaslicer will predict something like 6hrs but the print will actually take more like 8hrs.

• The jerks, accelerations and feedrates are also set to "Emit to G-code" in prusaslicer and not only used for the time estimation so I would think the predicted print times are as accurate as they can get.
• I do use FW retraction but in the above discussion, this was found to be kind of unrelated
• I also use input shaping but I would not expect that to make such a significant difference of adding 30% print time

I can also repeat some tests from above on my machine and post the results in this thread or a new one, but if you already know where the discrepancy might be coming from as you alluded to in the last comment, I am not sure if this would help anything.
If there are some configuration "errors" that are known to cause such a discrepancy, any hints would be appreciated.

[Phaedrux]

@Schild0r Can you try simulating the file and see what the simulated time ends up being?

Do you have a speed or accel limit set lower in your config.g than it's trying to use in the sliced file?

[oliof]

@Schild0r in my experience with Cura and PrusaSlicer, the estimates get better with higher accelerations; I managed to hit +-5min on Cura for prints running longer than an hour with accelerations >=2500; but only if the accelerations are set in slicer for estimates only.

[dc42]

@Schild0r one of the reasons for the discrepancy may be that by default RRF only uses jerk when it is necessary to avoid slowing down (mostly through curves) whereas Marlin-based firmwares use it all the time, because the motion algorithms they use can't cope with acceleration from zero speed or deceleration to zero speed.

You can get RRF to partially emulate that behavior using the J1 option of M566.

Over a year ago one of our users submitted a PR to PrusaSlicer to account for this when using RRF and estimating print times, but it wasn't merged.

[Schild0r]

@Phaedrux said in slicer printing time vs real printing time:

@Schild0r Can you try simulating the file and see what the simulated time ends up being?

Do you have a speed or accel limit set lower in your config.g than it's trying to use in the sliced file?

The simulation time compared to the slicer estimated time or to the actual print time?
According to prusaslicer the estimated print time is 6:41
Simulation says it is 7:34
I am actually not sure anymore about the actual print time and don't think I could look it up anymore unless I print it again. I might need to work on some sort of logfile generation...

My config.g contains these lines in regards to speed, acceleration and jerk

M566 X600.00 Y600.00 Z60.00 E300.00                        ; set maximum instantaneous speed changes (mm/min)
M203 X12000.00 Y12000.00 Z600.00 E3000.00                  ; set maximum speeds (mm/min)
M201 X7000.00 Y7000.00 Z20.00 E3000.00                     ; set accelerations (mm/s^2) 
M204 P5000.00 T7000.00                                     ; set printing and travel accelerations
...
M593 P"MZV" F36.2                                          ; use MZV input shaping to cancel ringing at 36.2Hz

My prusaslicer config looks like this

The travel accel is mismatching my config but since it is emitted to g-code this should not really matter
G-code and config.g is also attached if you want to simulate yourself.
a802e68d-cac1-4383-9455-10e8a97bbba4-PET-Laptopstand_20240803-005116.gcode
565a33ab-fb74-4946-a4ca-c5689ddfdebe-config.g

---

@dc42 said in slicer printing time vs real printing time:

@Schild0r one of the reasons for the discrepancy may be that by default RRF only uses jerk when it is necessary to avoid slowing down (mostly through curves) whereas Marlin-based firmwares use it all the time, because the motion algorithms they use can't cope with acceleration from zero speed or deceleration to zero speed.

You can get RRF to partially emulate that behavior using the J1 option of M566.

Over a year ago one of our users submitted a PR to PrusaSlicer to account for this when using RRF and estimating print times, but it wasn't merged.

hm that might of course explain part of it.
I tried the simulation with the P1 parameter and also with J1 (was that a typo since I dont see it mentioned in the gcode reference document?) but both made no difference to simulated print times (expected?)
I would of course like it better if Prusaslicer would actually implement the PR since there is already the gcode flavor selection so why not... any chance that this will be done at some point nevertheless?

On that note: do you know how prusaslicer handles firmware retraction in regards to print time calculation?
The retraction parameters will be greyed out when FW retraction is enabled so I assume it might just ignore it?
I created a feature request to leave the parameters active and use them for print time calculation. Let's see if this gets any attention.