Simulated time turns N/A before print ends

dc42

@JayT to clarify: is the AppendTimeLeft function you are referring to in the code for DuetWebControl, or somewhere else?

JayT

@dc42 : its from "UserInterface.cpp (PanelDueFirmware\src\UI)".

I am also running some tests. One thing that I confirmed with another print is, IF I keep bed heater & extruder heater ready, then in the same print, I don't see Simulated time to turn N/A in last few layers (unlike the case above for same print).

Can you infer something here?

JayT

@JayT
@dc42 : After few trials, we confirmed that since timer (job duration & the decrementing simulation time) starts immediately after pressing Print. Here if the bed & extruder temperatures are not attended yet, the warmup duration accounts only for bed heater time to attain target temperature. Extruder time to attain temperature is not accounted.
Hence we reach to condition (t<0) and simulated time completes displays N/A, while print is still running for few minutes.

2 methods to resolve this:

We account extruder temperature also in warm up duration
we start simulated time once Print actually starts (after warm up of bed & extruder)

What do you suggest ?
Do we evaluate time to attain extruder target temperature? Can you direct us to the code to change?

JayT

@jay_s_uk @dc42 :

Can anyone of you direct me to code that initiates decrement of Simulated time (decrement) that is displayed on Panel ? If we add a condition here to initiate decrement only if printing is initiated like that of progress bar, logic should work?

or how to evaluate warm up time of extruders to add to "warm up duration" ?

dc42

@JayT I looked at the PanelDue code recently and it already tries to account for warmUpDuration:

		if (simulatedTime > 0)
		{
			timesLeftText.copy(strings->simulated);
			AppendTimeLeft(simulatedTime + jobWarmUpDuration - jobDuration);
			++count;
		}

That's at line 1501 of https://github.com/Duet3D/PanelDueFirmware/blob/master/src/UI/UserInterface.cpp.

JayT

@dc42 : it accounts for WarmUp duration, but warmUpduration sometimes considers only Bed heater's time and not Extruder's time . One way I can fix it for my machine is by just including condition to start decrement of simulation time when actual printing starts.

Can you direct me where I can include this in the code, which code?

chrishamm

@JayT The warm-up duration is only increased while M109/M116/M190/M191 is executed so it should work for extruders as well. What's your start G-code?

JayT

@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
M107

Do 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

dc42

@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?

JayT

@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)?

chrishamm

@JayT Thanks, I could reproduce and fix this problem. You can work-around it by replacing

M109 T1 S190

with

G10 P1 S190
M116

JayT

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

dc42

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

JayT

@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?

dc42

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

0

chrishamm committed to Duet3D/RepRapFirmware

Fixed warm-up counter during M109

JayT

@dc42 @chrishamm :

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?

dc42

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