G10 heat "off" and M116 wait-for-temp don't work in print files

kenblu24

Scenario 1 solved: Tool 0 was not activated before the G10 command, so nothing happened.

As for Scenario 2, I've been using the macro workaround to solve that and I've updated to a new RRF with different G10 temperature behavior. So, I'm going to try it again now.

Phaedrux

Sorry I miss read your first macro as M104 S0 when you actually had M106.

ChrisP

@kenblu24
Out of interest, is there any particular reason that you don't just use an M0 as your slicer end code then put the rest of the end script you posted in cancel.g? That's what I do as the M0 turns everything off anyway so there's no need to alter standby/active temperatures?

Phaedrux

@ChrisP said in G10 heat "off" and M116 wait-for-temp don't work in print files:

in cancel.g?

Do you mean stop.g? M0 calls stop.g

ChrisP

@Phaedrux said in G10 heat "off" and M116 wait-for-temp don't work in print files:

@ChrisP said in G10 heat "off" and M116 wait-for-temp don't work in print files:

in cancel.g?

Do you mean stop.g? M0 calls stop.g

Funny you should say that. But I've found that if cancel.g is present, then that's what seems to be called. I spent a good hour tyring to figure out why my code in stop.g wasn't working the other day, and found that it was calling cancel.g instead. Indeed, careful reading of the wiki states exactly this for M0:

"The firmware finishes any moves left in its buffer, then it executes the macro file cancel.g if present, if the axes are homed and if a print is being cancelled. Otherwise stop.g is run..."

I initially expected it to be like you think, and would probably prefer it that way.... but it seems not to be.

Phaedrux

@ChrisP said in G10 heat "off" and M116 wait-for-temp don't work in print files:

and if a print is being cancelled.

That would mean to me that a print has been paused and then canceled.

I definitely use stop.g as and M0 as my end gcode and it works as expected. I have both cancel.g and stop.g present with different code.

ChrisP

@Phaedrux said in G10 heat "off" and M116 wait-for-temp don't work in print files:

@ChrisP said in G10 heat "off" and M116 wait-for-temp don't work in print files:

and if a print is being cancelled.

That would mean to me that a print has been paused and then canceled.

I definitely use stop.g as and M0 as my end gcode and it works as expected. I have both cancel.g and stop.g present with different code.

I appreciate that that's what I@d also expect it to do, but following your post, I've just gone and tested and cannot confirm that this is the case.

For the test, I edited the contents of my cancel.g file in the /sys folder to:

M291 P"cancel.g was called" S1`

and similarly, the contents of stop.g to:

M291 P"stop.g was called" S1

I then made a gcode file and put it in the root of my gocdes folder. This is the contents (interestingly, if I delete the first commented line DCS crashes... but that's a seperate issue):

; G-Code generated by Simplify3D(R) Version 4.1.2
G90
M0

Running the file as a normal print, this is what I'm presented with:

Finally, this was the output of the DCS log:

[debug] IPC#10: Got new UNIX connection, checking mode...
[debug] IPC#10: Command processor added
[debug] IPC#10: Received command SimpleCode
[debug] Waiting for execution of M32 "0:/gcodes/test.gcode"
[debug] Processing M32 "0:/gcodes/test.gcode"
[info] Selected file /opt/dsf/sd/gcodes/test.gcode
[info] Starting file print
[debug] Completed M32 "0:/gcodes/test.gcode" => File 0:/gcodes/test.gcode selected for printing
[debug] Waiting for execution of ; G-Code generated by Simplify3D(R) Version 4.1.2
[debug] Processing ; G-Code generated by Simplify3D(R) Version 4.1.2
[debug] Waiting for execution of G90
[debug] Completed ; G-Code generated by Simplify3D(R) Version 4.1.2
[debug] Waiting for execution of M0
[debug] Processing G90
[debug] IPC#10: Connection closed
[debug] Processing M0
[debug] File: Sent G90, remaining space 1512, needed 24
[info] File: Optional macro file start.g not found
[debug] File: Suspending code G90
[debug] File: Sent G90, remaining space 1512, needed 24
[debug] File: -> Resumed suspended code
[debug] Requesting update of key job, seq 32 -> 34
[debug] Completed G90 =>
[debug] File: Sent M0, remaining space 1512, needed 24
[info] Finished printing file 0:/gcodes/test.gcode, print time was 0h 0m
[info] Executing nested macro file cancel.g on channel File
[debug] ==> Starting code: M0
[debug] Waiting for execution of M291 P"cancel.g was called" S1 (macro code)
[debug] Processing M291 P"cancel.g was called" S1
[debug] File: Sent M291 P"cancel.g was called" S1, remaining space 1476, needed 60
[debug] Updated key job
[debug] Requesting update of key job, seq 34 -> 35
[debug] Completed M291 P"cancel.g was called" S1
[debug] File: Finished macro file cancel.g
[debug] Completed M0 =>
[info] Cancelled job file
[info] File: Finished macro file cancel.g
[debug] File: ==> Starting code: M0
[debug] Updated key job
[debug] IPC#11: Got new UNIX connection, checking mode...
[debug] IPC#11: Command processor added
[debug] IPC#11: Received command ResolvePath
[debug] IPC#11: Connection closed
[debug] Requesting update of key job, seq 35 -> 36
[debug] Requesting update of key state, seq 12 -> 13
[debug] IPC#12: Got new UNIX connection, checking mode...
[debug] IPC#12: Command processor added
[debug] IPC#12: Received command ResolvePath
[debug] IPC#13: Got new UNIX connection, checking mode...
[debug] IPC#13: Command processor added
[debug] IPC#13: Received command GetFileInfo
[debug] IPC#12: Connection closed
[debug] IPC#13: Connection closed
[debug] Updated key job
[debug] Updated key state

and as you can see, cancel.g was called, not stop.g.

However, if i delete cancel.g and re-run the job, stop.g is called. Try it

ChrisP

Hmm, I suspect we both might be correct if you're not running RRF3. I am, and in the source of GCodes2.cpp, the processing for M0 (and M1) starts at line 441. On line 464 there's this:

// If we are cancelling a paused print with M0 and we are homed and cancel.g exists then run it and do nothing else
if (wasPaused && code == 0 && AllAxesAreHomed() && DoFileMacro(gb, CANCEL_G, false, 0))
{
	break;
}

which will call cancel.g as part of evaluating the 'if' irrespective of whether the print was paused (which in the test I presented above, wasn't the case).

Interestingly, this won't actually do quite what the comment might at first appear to be saying. Perhaps it's a bug? Maybe not though as the behavious does seem to match the description in the wiki. Perhaps @dc42 can clarify?

Phaedrux

Currently still Duet2wifi and RRF2.05.1, so that may explain the discrepancy.

I recall some discussion recently about M0 I'll see if I can find it.

Phaedrux

https://forum.duet3d.com/topic/13927/m0-h1-running-stop-g-instead-of-cancel-g?_=1586279994538