G10 heat "off" and M116 wait-for-temp don't work in print files
-
Scenario 1: I upload a file with this at the beginning. The M116 command doesn't make the printer stop and wait for the temperature to be reached.
G90 M82 M106 S0 M140 S55 M116 H0 S3 G10 P0 S240 M116 P0 T-1 T0 ;Select tool 0Scenario 2: At the end of a print, this gets run.
;set all heaters to standby ;M104 S0 ;extruder heater off M140 S-300 ;heated bed heater off THIS ALSO DOESN'T WORK G91 ;relative positioning G1 E-1 F600 ;retract the filament a bit before lifting the nozzle to release some of the pressure G1 Z+0.5 E-5 F600 ;move Z up a bit and retract filament even more G1 Z+0.5 X-20 Y20 F1200 ;move the head out of the way a bit G90 ;absolute positioning T0 G10 P0 R-300 S-300 ; THIS DOESN'T WORK T-1 ;De-select all tools M98 P"heatersoff" ; THIS WORKS FOR SOME REASON G1 F6000heatersoff:
G10 P0 R-300 S-300 M140 S-300 M99For some reason, using the console/macros for the M116 wait and G10 "off" commands works, but not if it's in a print file.
-
It won't wait for 0 because it will never be reached. I think the limit is 45. So try 46.
-
M116 tells RRF to wait until the previously set temperature is reached. M116 commands do not take the temperature as a parameter.
The behavior I expect in Scenario 1 is: G10 P0 S240 sets tool 0 to 240C active temp. M116 P0 tells the machine to wait until tool 0 reaches the 240C active temp.
This works if I run the commands in the console, but not in a print file. It's as if the M116 command isn't even there.
-
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.
-
Sorry I miss read your first macro as M104 S0 when you actually had M106.
-
@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? -
@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
-
@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.
-
@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.
-
@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" S1I 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 M0Running 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 stateand 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
-
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?
-
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.
-
