slic3r_vars: Enable slic3r parameters to be read from gcode

[whi-tw]

Slic3r (and prusaslicer / SuperSlicer) can output all their parameters into the gcode file it creates.

This allows these to be read within macros while printing:

{printer.slic3r_vars.extruder_offset} == "0x0,20x0" for example.

[pedrolamas]

This is currently done on Moonraker side (it parses the GCode to retrieve certain features, such as the startup hotend and bed temperatures).

Having said that, I understand why you would want this on Klipper side for macros, but I don't think this is actually necessary for that purpose, as you can do this manually on any slicer just by adding parameters to your START_PRINT custom macro (just as you probably currently do for the startup temperatures!)

[whi-tw]

For sure, fully understand that it's possible to do in other ways, but I find the start gcode really difficult to read and keep up to date.

You end up writing a load of supporting code in the macros, which just read these parameters into variables anyway - it's not even as if klipper automatically pulls certain settings in, you still have to do some kind of processing.

Now I've started using my fork, my start gcode in the slicer is just START_PRINT, and I do the processing of the config from within the macro. If I want to make any changes to my macros, I just read in the new variables, rather than having to find out what SuperSlicer refers to them as, and passing them in as extra parameters (which then have to be propagated throughout any sub-macros)

My macros are mirrored here: https://github.com/whi-tw/klipper-macros, and my START_PRINT is here.

[KevinOConnor]

Thanks. It seems interesting, but as a high-level comment, I'm not really sure what this does or the benefit it provides to users. I'm going to mark this as needing a reviewer that can weigh in on the benefit.

-Kevin

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[github-actions]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.