Simulated time turns N/A before print ends
-
@chrishamm :
Thank you for reply.
Starting part of the Gcode is as follows.
;FLAVOR:RepRap
;TIME:10417
;Filament used: 12.9333m, 17.0185m
;Layer height: 0.3
;MINX:227.3
;MINY:241.8
;MINZ:0.3
;MAXX:357.798
;MAXY:358.2
;MAXZ:16
;Generated with Cura_SteamEngine 5.0.0
T0
M190 S60
M104 S190
M104 T1 S190
M109 S190
M109 T1 S190
M82 ;absolute extrusion mode
G1 Z15.0 F6000 ;Move the platform down 15mm
;Prime the extruder
G92 E0
G1 F200 E3
G92 E0
M83 ;relative extrusion mode
G1 F1200 E-1
;LAYER_COUNT:50
;LAYER:0
M107Do you find any problem in above code?
Observation: Generally the time when simulated time = N/A , print runs for 4-7 mins more.
What do you suggest ?600_dual file_2h53m_90g.gcode
-
@JayT do you still think the problem is what the estimate calculated from simulating doesn't take account of heating time?
What should happen is that while the printer is heating up, the estimated time left calculated from the simulation should stop counting down until heating is complete. Is this what you observe?
-
@dc42 : Yes for latter point.
-
When I connect DWC warm up time = bed heating time. IT does not account extruder heating time. so instead of >3mins, I get warmupduration = 30-40s
-
Since simulation count down starts as soon as print is clicked, extruder (that takes 3-4 mins)-heatingtime is lost. So at the end, when 3-4 mins of printing is pending, simulation time displays = N/A.
So As you stated, either in the code we have to stop counting down until extruder is heated up. OR Account warm up duration of extruder.
As per Gcode above, do you see reason why extruder time is not accounted?
I want to fix this by stopping simulation time count down until extruder heats up. how to do that? (which code file to check)?
-
-
@JayT Thanks, I could reproduce and fix this problem. You can work-around it by replacing
M109 T1 S190
with
G10 P1 S190 M116
-
@chrishamm :
Thank you.
So you are suggesting to modify this in Gcode each time?What if I don't want USER to each time modify this in Gcode? Can we do some setting in CURA to generate like this?
OR Update something in code?
P.S.: I will try this and let you know if this fix works at my end too. but looking for a solution where-in USER need not modify Gcode each time.
-
@JayT we've fixed this in RRF 3.5.0-beta3 which we hope to release later today. I have also back-ported the fix ready for the 3.4.6 release.
-
@dc42 : Thanks David.
I will wait for it.
But my problem is for one customer I need to fix this on urgent basis. Can you share the fix from Github branch for me to incorporate quickly ?Also can you suggest what all things we need to align in Slicer, to get simulated time = slicer time?
-
@JayT the commit to the 3.4-dev branch is this one https://github.com/Duet3D/RepRapFirmware/commit/5a5976a0e87fb6b2b05feaf8028b38229caf3459. It's not tested in 3.4.x yet.
The closest correspondence I have seen between simulated and slicer-estimated time was when the slicer was n8bot's fork of PrusaSlicer, with firmware set to RepRapFirmware and the machine parameters fetched from the Duet over the network. Last time I checked, the associated PR hadn't been accepted by Prusa yet.
-
Thanks. I would try that.
However, with this fix, do I have to fix the Gcode each time to include M116 as Chris stated above?Still sometimes I see job duration time != (simulation + heating time). what can be the cause for this?
-
@JayT changing the M109 command to M104 followed by M116 is a workaround for the bug. The fix to the RRF source code removes the need for the workaround.