slicer printing time vs real printing time

[milan.baca]

After some attemps, I found out that the thing which has big impact on printing time is filament jerk. I set up the Default filament Jerk in Cura, but in the generated code, there were no "M566 Ex" anywhere. So I am thinking the Cura ignores this jerk setting.

[Phaedrux]

@milan-baca said in slicer printing time vs real printing time:

I set up the Default filament Jerk in Cura, but in the generated code, there were no "M566 Ex" anywhere. So I am thinking the Cura ignores this jerk setting.

When you set those values in Cura it doesn't include them in the sliced gcode, it just informs it what your limits are.

I notice that your Z speeds are still set at the very low default values. This would make your Z axis very slow and unresponsive. Are you using Z hop by chance? It would definitely make layer changes longer than they probably need to be.

I would suggest experimenting with raising your Z speeds abit. I have a very heavy bed with a 1mm pitch/lead leadscrew and I use values that are higher than yours.

Try

M566 Z120			; Set maximum instantaneous speed changes (mm/min) (Jerk)
M203 Z600		; Set maximum speeds (mm/min)
M201 Z240 		; Set maximum accelerations (mm/s^2)

[milan.baca]

I do not use Z hop. Also I have heavy bed and 8mm pitch lead screw. But I will try increase max Z speed to 12 mm/s.

[milan.baca]

This post is deleted!

[garethky]

This is the most relevant thread to my observations so here goes:

Prusa Slicer says that Duet is slower than Marlin. Sometimes a lot slower.

Here are the baseline speed related settings we are working with:

M203 X{300 * 60} Y{300 * 60} Z{10 * 60} C{300 * 60}  E3600:3600:3600:3600    ; Max speeds (mm/min)
M201 X2000       Y2000       Z240       C400         E3000:3000:3000:3000    ; Max accelerations (mm/s^2)
M566 X{10 * 60}  Y{10 * 60}  Z{2 * 60}  C{0.6 * 60}  E600:600:600:600        ; Max instantaneous speed changes/Jerk (mm/min)

These limits have been entered into the slicer. My Duet printer has a lower top speed than the my Prusa MK3S (170mm/s vs 200mm/s). This means it cant hit the 180mm/s travel speeds in the default 0.2mm Quality profile. So that has been reduced in the slicer to be 150mm/s. Both printers have acceleration limits higher than the highest requested acceleration of 1500mm/s^2. I have further tweaked the profiles so I'm asking both printers to print the file at the same speeds. But I have given the Duet the benefit of the higher jerk limits in the slicer.

I have also tested by printing and I am sure that:

• The Prusa Slicer estimate is accurate and a Prusa MK3S will print these jobs in the time estimated.
• The Duet's simulation is accurate. Real print time reported in DWC matches the estimates closely.

I'm slicing and testing 2 models, one is the Benchy and the other is a bunch of parts for my extruder. since the Duet's simulation is accurate I should just be able to tweak settings and simulate until the two estimates line up, right?

Benchy slicer time estimate: 1h 33m 22s
Extruder Parts slicer time estimate: 5h 53m 57s

Now the Duet simulation times:

| What settings were tested?                             | Benchy     | Extruder Parts |
----------------------------------------------------------------------------------------
| stock settings                                         | 1h 46m 52s | 7h 13m 37s     | 
| pressure advance off                                   | 1h 47m 7s  | 7h 16m 48s     | 
| Jerk Policy 1 `M566 P1`                                | 1h 45m 55s | 7h  9m 53s     | 
| Raise X/Y/Z/E Acceleration by 10x                      | 1h 40m 24s | 6h 50m 42s     | 
| Raise X/Y/Z/E Jerk by 10x                              | 1h 38m 46s | 6h 30m 6s      | 
| Raise X/Y/Z/E Accel & Jerk to 10x, Jerk Policy P1      | 1h 31m 0s  | 6h 3m 49s      | 

So I was able to get very close to the slicer estimates, but I had to set incredibly high jerk and accelerations to do it. This is discouraging, because I cant operate a printer with (checks notes) 100mm/s of jerk in X and Y (on the MK3 its just 8mm/s!).

But I tried anyway! Starting at 20mm/s of x/y jerk the printer is positively violent. There is no way I would operate a printer like that.

The X/Y Jerk was the variable with the most impact on print time. This is not what I expected when I started the investigation. I thought my Z or E was killing me.

I don't understand this at all!

I don't think jerk is the right answer. Looking at both printers, they look similar in terms of how snappy they are. So I'm left to wonder:

• Is the clock in the duet is broken? It reports 7 hours of printing time but maybe the real time is less and we wont find this out without using an external timer?
• Is there a bug in the Core X/Y kinematics that fails to apply the speeds and/or accelerations requested?
• Aliens?

[T3P3Tony]

how about take a simple shape (hollow cube for example as a start point) and the compare what prusa slicer is outputting for the different printers. I know that more recent prusa slicer allows you to use the printers configured settings for time estimation. so it should be reasonably accurate. very high jerk will increase print speed in theory,, because any change in speed under the jerk limit will be done without acceleration - but that does not mean your hardware can physically achieve that velocity change without accelerating .

[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.