Splitting PRINT_START into pieces?

[jschuh]

Having one monolithic PRINT_START function creates some problems. The big thing is that you can't pause or cancel the current print when it's inside a macro (the pause/cancel gets fired, but it doesn't actually take effect until returning all the way up the macro stack and reading the next line of input).

The other thing is that many people have expressed the desire to run operations at different stages within PRINT_START. I could do this by adding more options like variable_start_gcode_before_print, but gets a bit messy and confusing. Whereas it seems pretty easy to just let people intersperse those things in their slicer's start gcode (or wrap the phased macros).

Right now I'm thinking of solving this by splitting things into the following five, ordered phases:

• _PRINT_START_PHASE_INIT - This phase is the config setup and sets the initial target for the chamber and heater.
• _PRINT_START_PHASE_PREHEAT - This phase stabilizes the chamber and heater at their target temperatures.
• _PRINT_START_PHASE_PROBING - This phase is all the probing operations performed at bed/chamber temp, including bed mesh, quad gantry leveling, etc.
• _PRINT_START_PHASE_EXTRUDER - This is the phase where the extruder is stabilized at its final target temp.
• _PRINT_START_PHASE_PURGE - This phase is just drawing the purge line.

I'd update the installation guidance to just direct people to paste this block of macros into their slicer's start gcode field. And to avoid breaking existing configurations I'd keep a legacy PRINT_START that behaves exactly as it does today by just calling all these macros in order.

Thoughts?

[jschuh]

I have an implementation of this up on the print_start branch. I'd appreciate anyone giving it a try to see if the new config works (the instructions are in the readme on the same branch).

I've tried it on some of my machines and it seems to work properly, but there are certainly other configs I can't test for.

Also, I should warn that I may make force pushes to this branch. So, if you see that your local print_start branch is out of sync on a git pull, remember that you can fix it with a git reset --hard origin/print_start

[lettore]

it's super useful, as you said with a single PRINT_START command when you want to cancel the print for any reason you have to wait until it finish or do an emergency stop.

[lettore]

I saw you put the chamber heating in init phase, I usually do the opposite because the chamber heater is very energy consuming and there's no need to warm the printer in the first layers, also because the first layer sometimes fails and you end up with a chamber at full temperature for nothing.
I observed that turning on the chamber only at the end of the start code made no difference just because the bed will warm the chamber by itself and there's little need to warm more with the chamber heater.

[jschuh]

I have it in front because my impression is that most people want to heat soak the chamber early, to account for bed flex, frame expansion, etc. That stated, I think the flexibility of this approach is that you can just not include the chamber in the PRINT_START arguments, and use the slicer start gcode to put the chamber heating wherever you want if it doesn't fit the normal PRINT_START pattern.

[M3HNGRY]

Nice to get us some status during the process for our leds be great too! Chamber addons be great as well.

[gcode_macro status_off] [gcode_macro status_ready] [gcode_macro status_part_ready] [gcode_macro status_busy] [gcode_macro status_heating] [gcode_macro status_cooling] [gcode_macro status_leveling] [gcode_macro status_homing] [gcode_macro status_cleaning] [gcode_macro status_meshing] [gcode_macro status_calibrating_z] [gcode_macro status_printing]

V/R
Anthony

[jschuh]

I think I've decided out how I want to handle this. I'm planning to implement a generic status system where you can register gcode to get called on different events. The implementation will be just like the layer events, but instead of getting called on layer changes it will get called on status changes. So, callers can wire up the events by just calling the event registrations from the _km_options gcode, which will get run at startup.

It would look something like this:

[gcode_macro _km_options]
# Options variables declared here
gcode:
  SET_STATUS_EVENT STATUS=busy COMMAND=status_busy
  SET_STATUS_EVENT STATUS=ready COMMAND=status_ready
  # And more lines like this for every status.

[jschuh]

Okay, this landed on main in v0.8.0.