add SET_PRINT_STATS_INFO G-Code for pass slicer variables to Klipper

[meteyou]

This adds a gcode called SET_PRINT_STATS_INFO that can be used insight the slicer to pass variables like the total layer count and current layer information to Klipper.
This would, of course, also be possible with a macro, but I would prefer an integration in Klipper, as this solution is then automatically available for every client.

To use the layer count, you have to include it in the "Custom G-code" in the slicer. Perhaps SuperSlicer integrate this directly.

Example for PrusaSlicer:

# "Start G-code" (above of your start_print gcode)
SET_PRINT_STATS_INFO TOTAL_LAYER=[total_layer_count]

# "After layer change G-code"
SET_PRINT_STATS_INFO CURRENT_LAYER={layer_num + 1}

The TOTAL_LAYER and CURRENT_LAYER will be automatic reset in SDCARD_RESET_FILE.

Thx to @zellneralex for the main idea/implementation!

[meteyou]

a small addition and good idea from @pedrolamas:

it would be also possible to add this gcode via moonraker preprocessor (like the exclude object gcode).

[zellneralex]

Looks ok for me

[KevinOConnor]

Thanks. I don't really have an opinion on this (other than the command should probably be more descriptive). I'd like to see others comment on this. It is a bit unusual for us to create a command just to standardize the command name.

-Kevin

[zellneralex]

Hello Kevin,

first sorry for the following wall of text but I feel it is needed to clarify the motivation of that PR.

The reason is not to standardize the command name, the real reason is to standardize the variables that are needed by the UI to show that information.

printer.print_stats.layer_current
printer.print_stats.layer_total

These are needed by the UIs to accurate show the total and current layer the print is at. I know we can argue now if that information is useful or needed but the simple fact is that many users want to have these information shown in the UI and requested it at fluidd and Mainsail.
Both UIs implemented it than in the way that they took the object height and layer height from the meta data to calc the total layer count and the actual Z during print and the layer height to calculate the current layer. That works somehow but has some inaccuracy e.g. when using z-hops and is totally wrong if you use features like "variable layer height".
These inaccuracies has generated questions in the discords and also user wanted to generated bugs against the UIs because of that.

I personally startet than to analyze if klipper itself could generate these information by analyzing the gcode file while loading it at print start. This method has for me the following downsides:

1. It delays the print start as klipper needs to read the complete gcode file at least once. We talking here about seconds. Also the experience with the exclude object post processor in moonraker shows that that can last long, we taking here about times in the region of 10-20 sec for large files.
2. klipper will run in the same uncertainties to differentiated a z-hop from a real layer change

We than came to the conclusion the best place to do it is the slicer as it knows when it adds a real layer change and should also know what the current and total layer is. And regardless if the user adds a call of a GCODE (or macro) in the layer change gcode section or by a postprocessor done in moonraker that will give us the most accurate information.

I know that this could be done with a custom macro (In this case 2 as we would need an override of SDCARD_RESET_FILE). But to be honest the UI would need to do a lot of extra stuff to secure against the case that the 2 variables above are missing. Also the experience with fluidd.cfg/mainsail.cfg and timelapse.cfg (all containing necessary setups and macros) has shown that many user struggling with simple tasks like adding them or run in problems as we need to do overrides to existing GCODEs that generates conflicts in there own config that they are not able to solve.

In the end the only reason for the GCODE Layer is to fill the 2 status variable that then can be safely used by the UI, but for the UIs it is important to have these standardize place to read these information.

We at Mainsail where the opinion that LAYER is a good name for it but if you know a better one changing it would be a piece of cake

Best regards Alex

[pedrolamas]

As @zellneralex has very well pointed out, in Fluidd we experienced the same type of questions (and bugs!) regarding Current Layer Number & Total Layers Count.

I like the idea behind this PR: the new LAYER command is a basic status/metadata reporting tool, no more than that!

I'm not entirely sure of the name of the command though... as this is under the virtual_sdcard module, I wonder if SDCARD_LAYER or even SDCARD_REPORT_LAYER would be more appropriate!

---

Having said that, makes me wonder if a more generic approach should be explored: today we need the Layer Number & Count, tomorrow... who knows?

Why not make this a way for the slicer to pass metadata (key-value pairs) to Klipper that can then be retrieved by the UI?

[zellneralex]

@pedrolamas as much I like the idea of a general key value parser as an engineer as much I fear it from the user to UI perspective .
These general commands work fine internally where you can count on a kind of "contract" that the right key is used. The UI in that case must count on that the user uses in our example layer_current and layer_total and not current_layer and total_layer as keys what make it unpredictable again.

But in general it would be a good idea to parse slicer metadata inside klipper so that the user can use them inside the macros and I have seen PRs about that already. e.g. #4935 and you know how it ended ;-)

[pedrolamas]

But in general it would be a good idea to parse slicer metadata inside klipper so that the user can use them inside the macros and I have seen PRs about that already. e.g. #4935 and you know how it ended ;-)

A bit different as I don't want Klipper to parse anything, but to provide a command that would allow the slicer to directly pass metadata to Klipper... but in the end, I guess it might fall under the same category! 😁

[KevinOConnor]

Thanks for the explanation. So, to summarize:

• The Klipper UIs need information about the print that the slicer has.
• The slicers have the information, but don't have a standard way of exporting it. (It's sometimes exported in adhoc comments; slicer variable naming is not consistent between slicers.)
• It is technically possible to do this with macos, but it is not really feasible. The initial configuration and ongoing maintenance burden would be too high with macros.

Did I understand the above correctly?

If a new command is added to Klipper, what is expected to generate the command? Are users expected to modify the slicer config to emit them, are slicer developers expected to change the code to emit it, or is a post-processing step expected to alter the g-code to emit it?

-Kevin

[pedrolamas]

If a new command is added to Klipper, what is expected to generate the command? Are users expected to modify the slicer config to emit them, are slicer developers expected to change the code to emit it, or is a post-processing step expected to alter the g-code to emit it?

I believe there are two options there:

• users can change their Slicer settings to add said command on layer change (Prusa Slicer and derivatives have a section for custom G-code on the Printer Settings, Cura requires a post-processing script that is already included in the default installation)
• add a pre-processing script to Moonraker (like the existing object cancellation one) that will read/parse the current comments added by the slicers and enrich the G-code on the file with the custom command.

[zellneralex]

@KevinOConnor yes you summarize it correct and @pedrolamas already mentioned the 2 method that normally can be done. In case of SuperSlicer we might get it also included in the the slicer but I do not believe any other slicer will do it.

The user already needs to add stuff to there slicer to be able to use timelapse or to get metadata that moonraker can extract while uploading the gcode files.

[meteyou]

@pedrolamas and @zellneralex have already explained/completed most of this very well.

the name LAYER was only the shortest and simplest name for this specific use case. we could make it more generic if someone can think of other possible values for the future. maybe SDCARD_PRINT_INFO / SDCARD_PRINT_STATS for a generic command/gcode name and then we can add the attributes to it (in this case i would use LAYER_TOTAL and LAYER_CURRENT as attribute names).

[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.

[jschuh]

In case it helps the discussion along, I've had this layer tracking functionality in my own macros for a while.

I use it to schedule events at layer changes, such as pauses that don't mar exterior perimeters, or future temperature and fan (changes beyond the typical first layer stuff). All of that functionality can of course be done through the macro system, but I agree that the big gap is integrating with the UI. If I'm scheduling these events on a live print I inevitably have to use the console, since the UI's layers are an estimate that's often wrong (as @zellneralex described). However, this is the sort of thing that would integrate very nicely with the UI if it had accurate layer state.

I also have a few thoughts to add on the implementation:

• I don't know that it makes sense for this to be in the virtual_sdcard module, since it doesn't seem like there's a reason it can't function when not printing from SD. That does mean the command will need an explicit argument for zeroing/resetting the state (although implicitly resetting in SDCARD_RESET_FILE and CANCEL_PRINT seems like a good idea).
• If we're bikeshedding over names, I'll put in a vote for LAYER_CHANGE or maybe ON_LAYER_CHANGE, since it more accurately captures the intent in my opinion.
• I'd appreciate support for optionally tracking the printed Z height, for slicers that make this available.

[KevinOConnor]

Thanks for the feedback. I don't really have an opinion on this. I'm okay with adding the support if it is desired by the UIs.

I'd suggest some changes though:

1. Don't modify the virtual_sdcard.py module - this support doesn't seem related to it.
2. Call the command name SET_PRINT_STATS_INFO and place the command (and status information) in the print_stats.py module. For example: SET_PRINT_STATS_INFO CURRENT_LAYER=123
3. Export it as a separate "info" dictionary in the "printer status" information - for example: printer.print_stats.info.current_layer

@Arksine may have comments as the original author of the print_stats.py module.

Cheers,
-Kevin

[meteyou]

Thanks for your feedback!

I have implemented all the modifications and this is the new G-Code for PrusaSlicer:

# "Start G-code" (above of your start_print gcode)
SET_PRINT_STATS_INFO TOTAL_LAYER=[total_layer_count]

# "After layer change G-code"
SET_PRINT_STATS_INFO CURRENT_LAYER={layer_num + 1}

[KevinOConnor]

Thanks. It looks fine to me. As a minor thing, it seems odd that calling SET_PRINT_STATS_INFO without CURRENT_LAYER will actively clear the current layer.

I'll give a few more days to see if others have comments. If there are no further comments I'll look to commit.

-Kevin

[meteyou]

@KevinOConnor updated this PR to make it fit for the future for more attributes and now current_layer will only be updated when it is set or when you set a new total_layer.

@jschuh thx for your snipped. i only add a check, if one value is None.

[pedrolamas]

LGTM, I just tested the latest code and worked as expected!

@meteyou might be good to update the PR title (and maybe the initial post text?)

[D4SK]

Why make a klipper specific gcode command when most slicers aleary put this info as gcode comments.

You can check out my fork for an alternative approach where gcode.py broadcasts all gcode comments as an event, and a gcode_metadata module parses them based on the slicer used. This also allows for using the print time predictions put by the slicer. Unfortunately my implementation is more intertwined with the virtual_sdcard implementation etc. and cannot easily be merged. Maybe a stripped down version can be implemented into mainline klipper. I can certainly help with that.

[meteyou]

@pedrolamas thx! i updated the title and the description

@D4SK parsing comments feels wrong to me. i would rather build some kind of preprocessor into moonraker that converts the comments to gcode and then have klipper process it.

[KevinOConnor]

Thanks.

-Kevin

[stenmic]

how does it work with cura? I can't get it to work.

[pedrolamas]

how does it work with cura? I can't get it to work.

@stenmic use Klipper Preprocessor script for Cura