file_manager: Added additional metadata to aid tool selection on single extruder multi-material prints

[moggieuk]

file_manager: Added additional metadata to aid tool selection on single extruder multi-material prints

The added metadata is essential for single extruder multi-material printing. It is used in new Mainsail functionality to map tools to MMU spools when using Happy Hare (Klipper MMU driver)

Signed-off-by: Paul Morgan ([email protected])

[moggieuk]

This update allow for this new Mainsail functionality to map slicer tools to MMU lanes/gates at the start of a print

[Arksine]

Thanks. I'm fine with adding the new fields, however the metadata specification in the docs needs to be updated with the new fields.

moonraker/docs/external_api/file_manager.md

Lines 258 to 291 in a0164e1

	| Field | Type | Description |
	| ----------------------- | :------: | ------------------------------------------------------------ |
	| `size` | int | The gcode file size in bytes. |
	| `modified` | float | The last modified time in Unix Time (seconds). |
	| `uuid` | string | A unique identifier for the metadata object. |
	| `file_processors` | [string] | An array of `File Processors` that have processed |
	| | | and modified the file. |^
	| | | #file-processor-app-desc |+
	| `slicer` | string | The name of the slicer software used to slice the file. |
	| `slicer_version` | string | The version of the slicer software. |
	| `gcode_start_byte` | int | The byte offset in the file where the first gcode command |
	| | | is detected. |^
	| `gcode_int_byte` | int | The byte offset in the file where the last gcode command |
	| | | is detected. |^
	| `object_height` | float | The height (in mm) of the tallest object in the file. |
	| `estimated_time` | float | The estimated time to complete the print, in seconds. |
	| `nozzle_diameter` | float | The configured nozzle diameter, in mm. |
	| `layer_height` | float | The configured layer height, in mm. |
	| `first_layer_height` | float | The configured first layer height in mm. |
	| `first_layer_extr_temp` | float | The configured first layer extruder temperature, in Celsius. |
	| `first_layer_bed_temp` | float | The configured first layer bed temperature, in Celsius. |
	| `chamber_temp` | float | The configured chamber temperature, in Celsius. |
	| `filament_name` | str | The name of the filament used. |
	| `filament_type` | str | The type of filament used, ie: `PLA`. |
	| `filament_total` | float | The total length filament used in mm. |
	| `filament_weight_total` | float | The total weight of filament used in grams. |
	| `thumbnails` | [object] | A list of `Thumbnail Info` objects. |
	| | | #thumbnail-info-spec |+
	| `job_id` | string? | The last `history` job ID associated with the gcode. |
	| | | Will be `null` if no job has been associated with the file. |^
	| `print_start_time` | float | The most recent start time the gcode file was printed. Will |
	| | | be `null` if the file has yet to be printed. |^
	| `filename` | string | Path to the gcode file, relative to the `gcodes` root. |
	{ #gcode-metadata-spec }

I use VSCode's markdown table extension to keep tables formatted. In addition, Moonraker's docs makes use of my compact tables extension. This allows you to merge rows with long descriptions. When you see a carrot (^) at the end of a row it indicates that the row will be merged with the one above it. It also allows for nested tables with a +, but I don't think that will be necessary here. You can see the result here.

If you want to see a live result as you are modifying, you can create a virtualenv, install moonraker's doc requirements, and run mkdocs serve from Moonraker's root folder (ie: ~/moonraker).

[moggieuk]

Of course. Still learning my way around Moonraker. I'll update the docs..
BTW I like the compact markdown table idea -- I wish github would use for their wiki implementation!

EDIT: Documentation updated with new metadata variables. Note that I also clarified that two existing variables can represent multiple values for multi-color single-extruder prints.

[Arksine]

For consistency with the documentation it would be preferred for these types to be string rather than str. The docs are oriented toward JSON (JavaScript) type descriptions.

[Arksine]

I noticed that this is parsed as a string. Other temperatures parsed by metadata.py are expressed as a float, is there a particuar reason for this not to be? Is it because there may be multiple? Since this is a new addition it could be returned as a list of floats. I'm open to discussion on which is best.

[Arksine]

I wonder if we can shorten the name of this field and make it more descriptive. It seems this indicates that the print was sliced with MMU enabled, so I wonder if it would make sense to have this field be named has_mmu or has_se_mmu. The field names reported by Moonraker don't have to match the one's added by the slicer.

[Arksine]

Thanks. With the documentation I was able to get a better feel for what is being added, so I had a few comments. I'm open to leaving the filament_temp and single_extruder_multi_material alone, however I wanted to provide some feedback and open discussion on what could be IMO minor improvements.

[moggieuk]

Thanks. Happy to change the return types and shorten the single_extruder_multi_material name - I used that because that is what Prusa calls it and thus thought that seemed to be the precedence elsewhere.

As for types, yes, temp can be parsed an array of floats, in fact that is what I do in Mainsail anyway. Again I was really trying to pick up on conventions and missed the individual temps. I'm back from my trip so let me update..

EDIT: One possible concern is that many of the metadata variables used in the slicer can be scalar or an array. E.g. take the existing filament_type. This is currently a string but is really an array of strings, often with one element. Given that I'm sure, for backward compatibility, you don't want to change the meaning of that(?) I think it would make sense to leave the new filament_color, etc as string rather than to chop into string[]. If I do that it will be different from a couple of existing placeholders...
Taking that thought further, converting filament_temp into an array (float or string) does seem like a change of direction. What would you prefer?

[Arksine]

One possible concern is that many of the metadata variables used in the slicer can be scalar or an array. E.g. take the existing filament_type. This is currently a string but is really an array of strings, often with one element. Given that I'm sure, for backward compatibility, you don't want to change the meaning of that(?) I think it would make sense to leave the new filament_color, etc as string rather than to chop into string[]. If I do that it will be different from a couple of existing placeholders...

You are correct, we don't want to break API compatibility so filament_type should stay as is. We also have to consider that other slicers may not return multiple values for these fields.

I'd be fine with returning filament_color as a list, lets rename it filament_colors if we do that. That way the nomenclature indicates it will be an array of values, so the deviation from existing string fields makes sense. Likewise, we should probably rename filament_temp as filament_temps.

[moggieuk]

No problem. Let me update this.

[moggieuk]

@Arksine I have updated according to your guidance:
Shortened single_extruder_multi_material to mmu_print

The new metadata: filament_temps, filament_colors, extruder_colors are now all typed-lists. I added a convenience method to parse using alternative delimiters because not all slicers use , and ; consistently. These new metadata names are all plural to indicate lists whilst the two original filament_name and filament_type remain scalar strings. This at least gives the opportunity to duplicate with "plural lists" (which would be more accurate) in the future.

Let me know if there is anything else you would like changed.

[Arksine]

Looks good, thanks!

[moggieuk]

Thank you!

[pedrolamas]

I've just started adding support for this in Fluidd, here is a first draft of it: fluidd-core/fluidd#1617

I really dislike how the Filament Name and Type are now showing up (check the screenshot), so will try to do something "cleaver" around that...

---

Side note on this topic: I know I did this PR, but I wish I hadn't done it...