RRF3: Start Gcode file from within gcode file using M32

too

so the title pretty much sums it all up.

I want to automatically start a gcode file when the current job is ending, possibly using M32.

The reason for that is I am working with multiple meter large and tall prints and therefore giant files. If there is a fail during printing, it is usually not an option to scrap the part and start over.
I wrote a script that cuts a given gcode file at every individual object on a single layer into its own gcode file, to make the recovery procedure easier in case of a fail during the printing process, now I need a way to automatically call up each script.

dc42

I have been told that putting M32 command as the last command of a GCode file causes RRF to run that M32 command and start the new file, but I haven't tested that.

Are you aware of the resurrect facility? It uses the M26 command to start part way through a GCode file. So you could go back to using a single GCode file, and instead use a script to create a macro file that resumes the print at a chosen point.

littlehobbyshop

@too said in RRF3: Start Gcode file from within gcode file using M32:

M32

Could you not modify your splitting script to append M32 'nextfilename.g' to the end of each file? That would do it.

too

@dc42 @littlehobbyshop I tried that with two files, 'one.g' and 'two.g'

;one.g
g92 x0 y0 z0 
G1 X50
M400
M32 "0:/gcodes/dir_testing/two.g"

;two.g
G1 X0
M400
M32 "0:/gcodes/dir_testing/one.g"

If I start one.g, it runs successfully and gives this output in the console:
"Finished printing file 0:/gcodes/dir_testing/one.g, print time was 0h 0m"
and right after that I get this message:
"Error: M32: A file is already being printed"

The problem with M26 is that sometimes the fault is only recognised after a while, so somehow you would have to "go back" a unknown amount of moves, so having individual files for each wall object would make that a lot easier.

EDIT:
I'll try and see if I can work something out with M28.

littlehobbyshop

@too Hmm, that makes perfect sense. i'm not sure where you are heading with M28?

It seems you might be able to achieve this if you run the files as Macros using M98/99 rather than prints. I've not tried it but i think that the only affect would be the status indicator would be 'Busy' instead of 'Printing'.

Running a macro from another macro is allowed. You could have one master macro that would run all the others rather than the above chaining technique which would end up in a very deep tree of macros.

too

@littlehobbyshop
well, for a gcode that short it would work using macros, yeah. but if I want to print say 100 or 1000 files that might get a bit messy without the print control interface? also pause would not work either?

My idea for m28 is to change a macro file to start the next print, but I ran into other issues there.

too

Alright, I have finally found the time to do some more tests.
Turns out on the Duet2 wifi I can actually just call M32 to start a new gcode file. On the Duet3 however, that doesn't work.

M32 0:/gcodes/chopped_retraceCube/retraceCube0001.g

On the Duet2 wifi I can also use M28 to overwrite a macro file from within a gcode file to contain a single M32 command that starts the next gcode file. This is not working on the Duet3 (see this topic)

M28 0:/macros/startnext 
M32 0:/gcodes/chopped_retraceCube/retraceCube0001.g 
M29 
M98 P"0:/macros/startnext"

The only downside to this is a messed up layer statistic. because it starts a new gcode file each time, it will reset the graph. Also, the name of the current file does not update.
I will see if I can work around that issue by overwriting the current gcode file.

chrishamm

M32 will be fixed for this use case in the next DSF version.