layer cooldown: Issue and possible fix  

RE: layer cooldown: Issue and possible fix

Add a pause to the Before Layer gcode.   There are filament cooling values that also may be useful.

G4

Pause the machine for a period of time.

Parameters Pnnn Time to wait, in milliseconds Snnn Time to wait, in seconds

Example G4 S2 Waits for 2 seconds.

RE: layer cooldown: Issue and possible fix

Thanks.  I was, however, hoping for a way in PrusaSlicer to do it without post-processing the gcode.  Something like a min layer time which forces a layers to pause if the print time is below a certain threshold (and understands the tool change time).  If not already present, this seems like a good feature to add.

RE: layer cooldown: Issue and possible fix

prusaslicer has a built in place to add before layer ( or after layer) code

RE: layer cooldown: Issue and possible fix

Very good.  Allows me to add time to all layers but not quite what I want since it will continue to add delay even after color chages start.  I see the if-else clause in the End G-code section which looks promising.  If I could add a (if Z<10) or (if layer<50) that would do it.  I found a page with the supported Prusa Gcodes but not anything with supported compiler directives.  What other options are there beside "has_wipe_tower"?

RE: layer cooldown: Issue and possible fix

Posted by: @ron

Yes, something like

{if layer_num <= 50}G4 S10{endif}

or

{if layer_z <= 10}G4 S10{endif}

in "Before layer change G-code.

More about macros: https://github.com/prusa3d/PrusaSlicer/wiki/Slic3r-Prusa-Edition-Macro-Language

Awesome!  This is perfect - and thanks for the link.  Lots of useful info there!

RE: layer cooldown: Issue and possible fix

Posted by: @ticktock

Very good.  Allows me to add time to all layers but not quite what I want since it will continue to add delay even after color chages start.  I see the if-else clause in the End G-code section which looks promising.  If I could add a (if Z<10) or (if layer<50) that would do it.  I found a page with the supported Prusa Gcodes but not anything with supported compiler directives.  What other options are there beside "has_wipe_tower"?

layer_z will give you the current Z height, and as @ron notes layer_num will identify the current layer. Most, but not all, of the "placeholders" correspond to slicer parameters and can be found in plain text at the end of your generated gcode. Keep in mind that all of the "smarts" are in the slicer, not the printer. There are rudimentary conditionals, but those are all done by the slicer, not at print time.

RE: layer cooldown: Issue and possible fix

I have added a feature request for an additional scalar (layer_print_time) which provides the estimated print time for the prior layer for use here.  The previous suggestions are great but require hand editing the macro for each model.  If I could qualify the pause in response to the estimated layer time, I could just leave it in place and not have to manually tune it.  Ideally, I would make the pause be for the exact amount required to reach a set time. (i.e. G4 S(300-layer_print_time)  (with proper range checking)).

RE: layer cooldown: Issue and possible fix

Posted by: @ticktock

I have added a feature request for an additional scalar (layer_print_time) which provides the estimated print time for the prior layer for use here.  

That's a great idea! I do worry about the limited conditionals available in PrusaSlicer/Slic3r being able to do exactly what you want. You'd almost need to know what your following layer times are in order to slow the first layers down to match.

In the meantime, one approach might be to use a post-processing script to interpret the M73 commands in the generated gcode.

The format of the new M73 code is the following:
M73 Pxxx Qxxx Rxxx Sxxx
where P is the percentage of the total time already printed in normal mode, R is the time remaining for normal mode in minutes, Q is the percentage of the total time printed in the stealth mode, and S is the time remaining to the end of print in the stealth mode.

Your post-processing script could compare the current R value to the previous to identify layer time. You'd need to make a pass through the entire gcode file to find your longest layer times, then another pass to insert appropriate pauses and movement. This would give you a bit more precision regarding actual times. I've written a similar post-processing script in python to identify the min/max XY movements in a print, and this wouldn't be much more complicated.

I suspect an Octoprint plugin could do this as well, although I haven't done much work on plugins myself.

RE: layer cooldown: Issue and possible fix

That is close to my feature request but for another need: https://github.com/prusa3d/PrusaSlicer/issues/2912

😉. Feel free to make yours as duplicate if you think it is.

RE: layer cooldown: Issue and possible fix

@bobstro

Thanks.  I found your page on the subject.  Very helpful.  Maybe you are right and I just need to up my game and add a post-processor.  Can I assume any language for which I've set up the proper paths to will work?  Or does it have to be python?

RE: layer cooldown: Issue and possible fix

Posted by: @ticktock

Thanks.  I found your page on the subject.  Very helpful.  Maybe you are right and I just need to up my game and add a post-processor.  Can I assume any language for which I've set up the proper paths to will work?  Or does it have to be python?

As I understand it, the two requirements for a post-processing script are:

1. It must accept the generated gcode filename as the sole command-line parameter.
2. It should generate a final output file with the same name so following scripts can work. (I just rename the original as a backup.)

Other than that, I believe you can use anything you like. I really like python, so that's just what I've used. I've read of PERL (!!!) being used and I suppose you could use just about anything else.

I need to update that example page. I load the ENTIRE gcode file into memory which has worked fine for me so far with 16GB RAM, but a safety check would be a good idea. Someday I'll re-write it to do multiple line-by-line passes but I'm not in a hurry.

RE: layer cooldown: Issue and possible fix

@ron

No, my request is different, but I see in the comments of your request a mention of a feature I didn't realize existed which is pretty much what I want (assuming it takes color change time into account properly):

@lukasmatena wrote: "There is a parameter in Filament Settings->Cooling->Cooling Thresholds that allow you to set a minimum time per layer and will slow down the print automatically so it is not shorter. It does not stop and wait, I think to prevent oozing. Does it not suit your needs?"