Awesome. thanks for this. I have also been wrestling with this issue (using a bed swapping mechanism though) and found another work around that might help some folks.

Simply upload your Gcode files in the macro folder and call them like a macro, from a master gcode file (one that can call the macro as many times as you like). I also put M99 at the end of the macro gcode file, but that was probably not needed.

Only downside of this is the status of the print is not shown like normal (no tracking of what layer you are on, % left, etc), as it thinks you are just running a macro... But the upside is that you can specify easily how many times to print in the master program.

I need to see if there is a way to specify the number of reprints using the trigger method. I am sure there is, but have not figured that out yet.

Toby

Just thought of another way to improve on this. Since the program that is next in the cycle is controlled by Trigger2.g (or whatever trigger number you use), This file should be able to be deleted and re-written with the M30, M28, and M29 commands in a macro.

That is assuming those commands will allow writing to a system file (I have not tested it yet).

This means a macro can be used to set the next program, and also start the first program. so you could have a macro for each production program you want to run....simple 1 click operation, once it is setup.

Just thought of another way to improve on this. Since the program that is next in the cycle is controlled by Trigger2.g (or whatever trigger number you use), This file should be able to be deleted and re-written with the M30, M28, and M29 commands in a macro.

That is assuming those commands will allow writing to a system file (I have not tested it yet).

This means a macro can be used to set the next program, and also start the first program. so you could have a macro for each production program you want to run....simple 1 click operation, once it is setup.

I am using a homing failure as a way to verify a build plate is present. (no build plate, no touching Z endstop, so print errors out before printing directly on the heated bed).

Is there anyway to start a "homingretry.g" code or something similar that runs when there is an error?

Awesome. thanks for this. I have also been wrestling with this issue (using a bed swapping mechanism though) and found another work around that might help some folks.

Simply upload your Gcode files in the macro folder and call them like a macro, from a master gcode file (one that can call the macro as many times as you like). I also put M99 at the end of the macro gcode file, but that was probably not needed.

Only downside of this is the status of the print is not shown like normal (no tracking of what layer you are on, % left, etc), as it thinks you are just running a macro... But the upside is that you can specify easily how many times to print in the master program.

I need to see if there is a way to specify the number of reprints using the trigger method. I am sure there is, but have not figured that out yet.

Toby