@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
f7a27788-c866-4250-998d-59f30f76b86e-image.png
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.
