Basic Information:
Printer Model: Custom
MCU / Printerboard: Manta M8P
Host / SBC CB1
klippy.log No
Describe your issue:
Hi !
I noticed some bugs in orcaslicer whit toolchanges and i needed to fix them by post processing the gcode file.
After some time, I have created an script in order to postprocess these G-code files right before starting a print so i don’t have to do it in the slicer, exporting the file and then loading it manually via the UI.
Basically, what i do is rename the sdcard_print_file macro, in order to call first a command that starts my processing script, and when finished, print the processed file (it overwrites the file). Anyways, this has a problem right now when files are too big as it stays processing the file until finished, and makes klippy go to shutdown. (Timer too close error)
I’d like to know if anyone has implemented something similar, with a more efficient workflow or if you have suggestions on how to optimize this.
Right now, I’m using the following approach in my macro:
[gcode_macro SDCARD_PRINT_FILE]
rename_existing: SDCARD_PRINT_FILE_BASE
gcode:
PROCESS_GCODE_FILE {rawparams}
SDCARD_PRINT_FILE_BASE {rawparams}
This macro calls the PROCESS_GCODE_FILE command i created, wich starts my processing script. After it finishes, the new file is saved in the same path, with the same name, and it is called to print this new file.
I have thought that one solution could be post process the file “in the background”, without blocking Klippy, but i dunno if this is really possible.
My current idea is to modify the macro to use a shell command instead of a normal command (i have the pluggin), executing the postprocessing with a Python script asynchronously. Here’s an example of what I’m thinking:
Something similar to this:
[gcode_macro SDCARD_PRINT_FILE]
rename_existing: SDCARD_PRINT_FILE_BASE
gcode:
RUN_SHELL_COMMAND python3 /path/to/postprocess_gcode.py --file={rawparams} &
SDCARD_PRINT_FILE_BASE {rawparams}
Would this be a reliable solution for large files, or is there a risk of Klippy starting the print prematurely?
Are there better ways to integrate this type of asynchronous postprocessing into Klippy?
Should I consider directly invoking the Klippy print command from the postprocessor instead of calling it in the macro?
Thanks in advance!