slicer printing time vs real printing time

Phaedrux

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

Has anyone a clue where the problem could be?

Are you setting acceleration in the slicer as well? That can help a bit to give the slicer a better idea of your limits.

PrusaSlicer has no way of knowing jerk either, so it's always going to be a little bit off. 33 hours is a long print too so the discrepancy gets exacerbated.

The best way to get an accurate estimate of print time is to run the gcode file through a simulation on the Duet. Then you'll know how long it will take quite accurately. For a very long print like that it may be worth the time it takes to simulate if you must know a completion time.

Otherwise, there's not much you can do other than use a slicer (like cura) that lets you input more details about the printer (max speeds, per print move speed/accel/jerk, etc) so that the slicer motion planner has an accurate idea of how the printer will behave. In cura I find that the estimates are within about 10 to 30 minutes even on very long prints.

milan.baca

I just tried Cure 4.5 set jerk and acceleration as in config.g and still times are totally different
printing time.png

Phaedrux

To get really good results from cura you may need to install the Printer Settings plugin and use it to input your printers max speeds, acceleration, jerk, etc.

So Cura thinks 33 hours and simulated time is 61?

Can you post your speed settings from config.g? Perhaps your max speed is set lower than the travel speed cura is trying to use.

milan.baca

M566 X720.00 Y720.00 Z12.00 E3000.00 ; set maximum instantaneous speed changes (mm/min)
M203 X7200.00 Y7200.00 Z180.00 E4200.00 ; set maximum speeds (mm/min)
M201 X3000.00 Y3000.00 Z100.00 E9000.00 ; set accelerations (mm/s^2)

milan.baca

Phaedrux

Phaedrux

Another thing to check is that you have Cura set to use RepRap Gcode Flavor

zapta

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

Are you setting acceleration in the slicer as well?

Does this impact the gcode generated by the slicer (e.g. to limit accelerations) or just inform its print time estimation algorithm?

Phaedrux

@zapta Both.

It generates a new acceleration and/or jerk command before each print move.

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:

Screen Shot 2021-02-17 at 5.47.21 PM.png

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:

Screen Shot 2021-02-18 at 4.26.53 PM.png

Screen Shot 2021-02-18 at 4.46.15 PM.png

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):

Screen Shot 2021-02-19 at 10.17.09 AM.png