Random print position on bed

[lettore]

When you print many identical pieces in the same bed position, the bed can wear very fast.
I added to my klipper START_PRINT macro a system for randomly move the print area so it's not always printed in the same place.
As I'm interested in using also this set of Macros, I need to rewrite the whole thing to make it compatible with your code.
If it's interesting I can share the code I'm using now as a base for implementing the function.

[ajshell1]

I'm not the maintainer, but Klipper Adaptive Meshing and Purging has something similar for it's pre-print purge/draw macro, as well as something for probe positions.

Having tried both KAMP and this, I've never had any issues with this, but KAMP gave me a few problems, mainly causing errors when the purge line attempted to go off the bed if I set the purge line too long.

Plus, I prefer this setup's back-and-forth purge block over KAMP's one big thick line approach, and KAMP's voron logo purge seemed too complicated to set up. In fact, I was astonished by how well klipper-macro's purge blocks were at detaching PETG strings that had oozed out when my nozzle was heating up. It reliably leaves those nasty strings in the purge block. The traditional "line purge" often couldn't do that, skirts often couldn't do that, and KAMP's purges often couldn't do that.

That said, it probably wouldn't be impossible to add a bit of randomness to the purge location. Unless the purge block is already close to the edge of the bed,

Or are you also suggesting that you randomly move the print area for the whole print? Is that kind of thing even possible?

[lettore]

Yes randomly move the print area for the whole print, I'm already using this system for months and it's really nice as the bed is wearing uniformly.
What I'm doing is slicing the print centered on the bed with the 0 origin in the front left angle, as everyone I think.
Then in START_PRINT
set the max and min area available to print

  {% set print_area_min_x = 20 %}
  {% set print_area_min_y = 20 %}
  {% set print_area_max_x = 205 %}
  {% set print_area_max_y = 205 %}

area_min is coming from a parameter like your MESH_MIN and MESH_MAX

      {% set n_free_space_x = (print_area_min_x - area_min_x)|int %}
      {% set p_free_space_x = (print_area_max_x - area_max_x)|int %}
      {% set x_random = range(n_free_space_x, p_free_space_x)|random %}

then after macro triggered the bed mesh routine it set a gcode offset

SET_GCODE_OFFSET X={x_random} Y={y_random}

Obviously you have to handle this offset when you do a pause or filament change otherwise you can go out of bonds.
For this I save the state before as SAVE_GCODE_STATE NAME=home and after with SAVE_GCODE_STATE NAME=printing so I can recall the state I need when printing or while in pause.
At print end and as first command in start print I have SET_GCODE_OFFSET X=0 Y=0 so also if something went wrong during printing I'm sure that at print start will pickup the right offset.

[jschuh]

It's an interesting idea and I had been thinking about it, but the first hurdle is that MESH_MIN and MESH_MAX won't work, since they bound only the first layer. That means that any other layer can end up printing outside those bounds. What you need is a union of MESH_MIN and MESH_MAX with the bounding box for the full height of the model.

There is the preprocess_cancellation script for object bounds, so you can trivially extract a bounding box from the exclude_object.objects entries. However, in my experience it doesn't generate a bounding box that's accurate enough for this kind of use (it's really intended only for graphical presentation).

I do have a Prusa Slicer patch I've been meaning to clean up and post as a PR for exclude_object. Since it uses Prusa Slicer's internal layer representation it generates an accurate bounding polygon for each object. I hadn't bothered to post a PR before because Prusa Slicer didn't explicitly support Klipper, but now that they have a Klipper gcode mode I could just make EXCLUDE_OBJECT_DEFINE just work automatically when "Label objects" is enabled.

It's not a difficult PR; probably only a few hours of work to polish off. But, even assuming Prusa Slicer accepts the PR, it would be at least a full release out, which means 6-12 months before it's available. And honestly, I haven't had great luck with Prusa Slicer accepting PRs.

Sorry, this is a bit rambly, but I've been thinking about this for a while and it seemed like a good place to collect my thoughts.

[lettore]

I personally use bounding_box from Superslicer PRINT_START AREA_START={bounding_box[0]},{bounding_box[1]},{bounding_box[2]} AREA_END={bounding_box[3]},{bounding_box[4]},{bounding_box[5]}
The third parameter is Z height

[jschuh]

Can't really speak to SuperSlicer. Last time I looked at it I didn't see features that made it compelling for me personally. I also noticed some stability issues and the codebase was maybe a year behind Prusa Slicer. So, I just maintain my own fork that closely tracks Prusa Slicer master and adds in patches for features I want. Of course, that means I have to rebase it whenever they do a major code dump to master, but it's usually pretty easy.

[lettore]

Yes I see Superslicer is not really up to date, but for me is working enough well. I tried also Orcaslicer but I found it a bit too minimal in options. Out of the theme, it would be nice to find a kind of converter that can convert profiles and settings from different slicers, so you can use the one you prefer.

[ajshell1]

Yeah, I used to use SuperSlicer a lot, but I've switched to PrusaSlicer, mainly because SuperSlicer is so behind. SuperSlicer had a bunch of advantages over PrusaSlicer when I first started using it, but that number has seriously dropped as PrusaSlicer has developed. Especially after PrusaSlicer added native Klipper support in their recent alpha/beta builds.

After a bit of searching, the only really "killer" standout features are the fact that SuperSlicer has a lot more options available for per-object modifiers (e.g. you can't set each part to have a different retraction length on PrusaSlicer, which sucks for retraction towers), the built-in calibration tests, and maybe the extra options for seam position control.

In the end it seems like I ended up not using most of the extra options that SuperSlicer added. And I find myself thinking that SuperSlicer's haphazard addition of extra checkboxes and textboxes are really messy.

[jschuh]

FYI, I just fixed up my old exclude_objects patch for Prusa Slicer to work with the Klipper gcode mode in the new beta. The output still looks right but I haven't actually run off any test prints with it yet (so it may be buggy). After it's tested I'll make a PR and we'll see how it goes (probably today or tomorrow).

[lettore]

I was looking at your code for implementing this function but I don't understand if the purge routine is checking if it can go out of the bed if the print size is nearly equal or bigger the platform.
I'm asking because in my START_PRINT macro there's a check that if bounding_box min or max is bigger than the print size it throws an error and not go forward.
This is useful because sometimes can happen that you have two printers with different sizes (example ENDER3 S1 PRO and PLUS) and there's no need to slice two different version of the same file. So with this system you can print small print also in bigger printer, and it's obviously possible also to center it to the platform using the gcode offset.
But it can happen also that you try to print a file bigger than the printable volume of the printer and it would be nice that the macro detect this before trying to print out of bounds.

[jschuh]

I've never hit the sort of problem you describe, but I'm happy to add more checking that catches errors before the print actually starts.

One other thing I should clarify is that I'm not comfortable relying on a feature specific to SuperSlicer. That's why I suggested using the exclude_object.objects entries, since it seems like the most portable approach. And after a bit of digging into it I'm now comfortable that the output from preprocess_cancellation is accurate enough for determining print bounds (assuming some padding at the edges).

Also, I did post an exclude_objects PR to Prusa Slicer, so maybe that gets merged in at some point and makes the whole process easier.

[lettore]

I got it today as I tried to print a print large as the printable area, the purge was made inside the print area because it's supposed to be or x mm away from the print or at the max printable area. Obviously is not desirable behavior.
I agree with the Superslicer specific feature, but I don't understand how it works the exclude_object.objects method, I mean the Superslicer way it's smart and obvious, a series of variables that you can insert anywhere in the Gcode section. As you use now MESH_MIN and MAX it should be added BOUND_MIN and MAX and passed to PRINT_START or _PRINT_START_INIT.

[jschuh]

I don't mind writing code to derive the model bounds from exclude_object.objects and place that in ["gcode_macro print_start_set"].settings. I'll do it in a patch that also sanity checks the bounds against the printable area (to address the case you mentioned here).

If you want you can just mock your code out with the parameters from SuperSlicer until I land mine in the next day or so.

[jschuh]

I have a working implementation of this up on dev branch. The macro is _km_check_and_set_print_bounds; it's called from _PRINT_START_PHASE_INIT and performs the following:

• Sets MODEL_MIN/MODEL_MAX based on the content of exclude_object.objects; if a MODEL_MIN/MODEL_MAX were passed in by the caller they will be incorporated into the calculation (so you can pass the bounding_box from SuperSlicer in your start gcode if you're so inclined).
• Sets PRINT_MIN/PRINT_MAX as the union of MODEL_MIN/MODEL_MAX and MESH_MIN/MESH_MAX.
• Aborts the print any of the supplied limits extend beyond the printable area.

[jschuh]

I decided to implement the whole thing over the weekend. I have it up on the dev branch, and it seems to work correctly. You can try it out if you like.

[jschuh]

I pushed the implementation to main this morning. The config variables are here:

klipper-macros/globals.cfg

Lines 82 to 85 in a7c928a

	# Maximum distance to relocate print in random XY location to reduce bed wear.
	variable_start_random_placement_max: 0
	# The relocation will be at least this far from the printable edge of the bed.
	variable_start_random_placement_padding: 10.0

The documentation for the two configuration options explains the additional configuration that's needed to make it work.

[xoga74]

Hello Justin,
I am using this function of random placing with succes for a time, Again Big thanks for your work

However when i encounter a power loss or other issue causing a firmware reset, i am not able to resume the print after this forced firmware resume since no info is saved on the applied offset.

I would like to be able to combine your work with the power loss recovery described in the macro of Travis90x : https://travis90x.altervista.org/klipper-power-loss-recovery-3d-print-resume/ .

Would it be possible that your macro saves the offset in the start macro and clears it in the end macro and before applying the offset checks if an offset was saved.

If an offset was saved and not cleared it would reuse the saved offset

Thanks in advance.
Nicolas