Update primeline so that it runs along the rectangle of the first layer

[elpopo-eng]

Thanks to @fbeauKmi

Now prime_line_xy defines the origin of the baseline
The primeline is made on the corner of the FL_SIZE rectangle closest to the origin.

Add Variable prime_line_margin wich define distance of purge line from fl_size rectangle

If FL_SIZE is not defined, old primeline is used

[Surion79]

i don't see the benefit of it except 2 seconds of travel. for me it looks overcomplicating stuff, including possible debugging.

Aside of that: This will fail after updating klippain via moonraker as it is defaulting on a non-existing variable.
also: this function should be available via variable. Because i don't want to use it. i want my primeline exact at the same place, all the time. even with bed mesh.

[elpopo-eng]

The aim is to place the primeline as close as possible to the bdemesh area.
If we place the primeline on the edge of the bed, you can engrave your PEI, but if you like that, we can introduce a variable to use the legacy primeline...

[Surion79]

Engrave? The location is so near the border, it would never get printed on anyway.

[Surion79]

Don't forget my other comments regarding breaking klippain on update without the default fix.

[Surion79]

The default on a non existing variable will break all installations which are updating existing klippain installations. Fix is to add another default with the default value. That was the solution @Benoitone suggested when we worked on the mmu verification of his branch.

[fbeauKmi]

Thanks for this PR @elpopo-eng . I think this is a nice to have. IMO the purge line should always be inside the bed mesh.Then it could be possible to go lower at the end of the prime line (Z<0.05) to wipe the nozzle on the bed.

@Surion79 If you don't intend to use this feature, you can remove prime_line from your startup sequence and then add it to your startup gcode in the slicer.

That's the beauty of Klippain being fully overridable ❤️ .

[Surion79]

Thanks for this PR @elpopo-eng . I think this is a nice to have. IMO the purge line should always be inside the bed mesh.Then it could be possible to go lower at the end of the prime line (Z<0.05) to wipe the nozzle on the bed.

@Surion79 If you don't intend to use this feature, you can remove prime_line from your startup sequence and then add it to your startup gcode in the slicer.

That's the beauty of Klippain being fully overridable ❤️ .

errr.... My Klippain tag is reading Collaborator, and i proposed a solution? I could also just push my proposal to the Klippain branch primeline_FLSIZE_dependent, but I won't.

Anyway, you don't override stuff by making users override existing functionality in klippain to tell them "do that in your slicer now".

[fbeauKmi]

Anyway, you don't override stuff by making users override existing functionality in klippain to tell them "do that in your slicer now".

No offense, override in Klippain if you prefer 👍

[Surion79]

still a no regarding overrides, because this change contradicts existing configuration in variables.cfg. without proper parametrization or setting an enable/disable variable, the prime line location is moved away from the settings in the variables.cfg.
i just ask for a variable to disable/enable this feature. i have no idea, why this is such hassle? it is a couple lines of code and a variable, additional to the variable which is already introduced by this PR.

something like enable_variable_primeline_placement or place_primeline_in_bedmesh

[Frix-x]

I appreciate the discussion surrounding this PR and the thoughtful contributions from everyone involved, but please keep it friendly. To address the concerns raised, here is my point:

1. The demand for adaptive purge integrated within Klippain is something that I get everyday on Discord or in PMs. As currently there is no solution in Klippain, I push the users over using KAMP. The problem is that using KAMP in Klippain is not that easy and can easily break the adaptive mesh: this create a lot of support work for me to help them going. So I'm definitely full on to integrate this to Klippain to have something just working out of the box.

2. The initiative for developing adaptive purge has been collaboratively discussed on Discord and is supported by contributions from Elpopo and Fbeaukmi since I had no time to develop it myself. This collaboration allowed to bring this PR and is also followed by a lot of people on Discord just waiting for it to be merged.

3. The concerns about a printed line (as the purge operation is doing) outside the meshed print zone are valid, particularly for printers with warped beds like Ender3, Prusa or Switchwire. This was mitigated by using a fixed height of 0.6mm for the prime line, but it was changed in a previous commit with an adjustable height parameter, that, while enhancing flexibility, also reintroduces the risk of crashes if using a small value closer to the print layer height like 0.2mm. Positioning the purge as close as possible to the part emerges as a prudent strategy to mitigate these risks.

4. Finally, I think that having adaptive mesh enabled by default sets a precedent for incorporating adaptive purge in a similar manner. Users can still not use the option by removing the SIZE parameter. I do not see any point in doing an adaptive mesh and not an adaptive purge or vice versa. On a good bed, it will be nothing more than a shiny feature but will not have any cons, on a warped bed it can avoid a crash.

This PR represents a step forward in aligning Klippain's features with the community's evolving needs and Klipper's advancements (like the adaptive mesh that is now mainline). So I'll review and test it properly to validate that everything is working and merge it in the current state.

[Surion79]

I still request to add a disable variable, so users can choose to make a bed mesh and an outside prime line.
It can be enabled by default.

@Frix-x Since i invested a lot of time to this project, i think it is not too much to ask.

[elpopo-eng]

@Frix-x we have chosen to always orient the primeline towards the centre of the bed (case 1) in order to avoid a possible end of prime_line outside the bed (case 2) and to have a simple code.
We can change this behaviour if you don't think it's correct.

case 1 :

case 2 :

[Frix-x]

Ok, I made some changes to make it a bit more flexible and cleaner:

• There is now an ADAPTIVE_PRIMELINE variable that you can use from your slicer to enable/disable the "adaptive mode" of the primeline directly from the START_PRINT sequence. By default, if nothing is set, it's True, so adaptive mode will be enabled for everyone unless we force it to be disabled.
• The PRIMELINE' macro can now also take an ADAPTIVE_MODE' parameter that allow you to set the behavior when calling it manually. I think this is useful because when called manually, there is no printing going on and I understand that someone would want to know where the primeline is going to be and not randomly put it where the last print was done.
• I've extended the SIZE parameter to work as it does with the bed_mesh by also allowing the exclude objects tags to be used when they are found and when SIZE is omitted. So in this case it will default to something like KAMP.
• I also added a very small move at the end to prevent the head from crashing back in the primeline if the slicer starts to emit a Z down move, as I noticed some actually do and this was asked multiple times by the community.

As my main printer is currently running for a couple of hours, can someone test it and let me know if everything is working ok?

outdated, changes were done

[Surion79]

I have currently an open printer and don't mind testing it. Anything specific to test? Fl size near the border?

(Just for testing i can activate it, not just in general for me)

[Frix-x]

New push, new tests needed before a final merge :)