Plater with visual export history of first layers to aid wearing surfaced print beds more evenly

[jammi]

Problem to solve Since many of us use disposable surfacing on our print beds, be it tape, hairspray on glass or whatever. It's almost impossible to place new models to print in areas of pristine or least worn surfaces.

Description of minimum viable solution I'd like slic3r to have a rough accumulating bitmap model of where the area covered by the first sliced layer of previous export to gcode / send to printer went. There'd be a reset button or menu item somewhere, if the feature is enabled (once bed is resurfaced etc). There'd be another checkbox in preferences to enable it.

Guesstimates of further development

• Have the bed history associated with either printer settings or have a concept of different printer profiles vs different printer, for people with many printers and therefore many print beds.
• Have some cool heatmap-style things
• Some progress bar gauge of how much virgin bed surface is left
• Automatic placement to avoid used areas; would find the smallest virgin area to fit the model(s) to print. Once virgin areas are all used up, go for areas used only once and so forth.

[jammi]

Some implementation suggestions

Output index

• Monochromatic bitmap exporting of a 1mm per pixel scale image using output from a variation of the same code that does the 2D and Layers plater.
• Let's say 32 monochrome bits per pixel in output format for good measure.
• Add 1 to the monochrome pixel value and store the max value in the index metadata

Rendering

• Render the image as a heatmap from min to max monochrome value of the output index
• Use the rendered image as a texture of the bed in the plater

[supermerill]

Problem 1: storing this information

Have the bed history associated with either printer settings or have a concept of different printer profiles vs different printer, for people with many printers and therefore many print beds.

I have multiple printers with the same profile. When i open slic3r on my desktop and i have printed something from my laptop yesterday, i have to get the "save file" from my laptop anyway, even if you create an overly complicated system. So I think we can leave the information in a good old save file.

Problem 2 : what to save

We can create some piece of code to save only the first layer, like cutting at 0.1mm. Anyway, the simplest way if we didn't want to spend months re-coding slic3r is to store & load a 3d model.

Problem 3 : updating the save

How to say "hey, i just printed that, please keep track of it". imo, it's loading the plater to update, add the current model to it and save it.

The workflow:

In the chat, you say that you forgot everything and the current workflow of "load slice print" shouldn't be altered.

But you have to also load the current state of the printer because slic3r can't know it.

But you have to also save the new state because slic3r can't know for sure if the print has been really printed.

The best workflow i can see (for you) is:

• load a 3d-object-plater-visual cue that load a 3d model like normal but mark it to not be sliced.
• load your model(s) to print
• move and modify the settings
• print the object(s)
• export plater as 3d object (optional : with a cut at 0.1 - 1mm for all models).

The step1 is the one we don't have. (and maybe a cut-and-save option)

The current workflow is:

• load a 3d-object-plater
• load your model(s) to print
• move and modify the settings
• delete the 3d-object-platter
• print the object(s)
• (optional : cut the object at 0.1 - 1mm)
• load the 3d-object-platter
• export plater as 3d object.

So if someone add the missing step (step1 of the first workflow), it should resolve your issue?

[jammi]

I have multiple printers with the same profile.

Since the feature would be optional to begin with, and most users have a single printer, and most users with multiple printers use different profiles, I'd vote for a simple 80/20 rule there; this feature doesn't apply to your niche use case of Slic3r.

Anyway, the simplest way if we didn't want to spend months re-coding slic3r is to store & load a 3d model.

There's a 2D renderer in place as is and the image doesn't have to be large resolution, 1mm per px should be pretty reasonable, simply include the pixel if there's been any extrusion overlap within it. The typical bed would therefore be a 32bit 200x200px; 160kB raw bitmap and would be usable as the surface texture of the bed in the Plater. There's only an STL option for custom beds as-is, but I don't think it'd be a major effort to include.

The workflow I'm after is a preparation of:

• Opening preferences or Printer → General → Bed and check the "[x] Use bed surface history"
• Clicking a "[Clear surface history]" button in the Printer → General → Bed section whenever the bed is resurfaced.

Usage would be like:

• Importing an STL
• Placing the model on the Plater avoiding previously used areas
• Clicking the "[Send to printer]" button in the Plater
• Not unchecking the "[x] Add to bed surface history" checkbox in the printing settings dialog
• Clicking the "[OK]" button and wait for the print to finish

When exporting to a gcode file:

• Importing an STL
• Placing the model on the Plater avoiding previously used areas
• Clicking the "[Export G-code]" button in the Plater
• Not unchecking the "[x] Add to bed surface history" checkbox in the file saving dialog
• Clicking the "[Save]" button and uploading the file to the printer manually

[supermerill]

For such extensives changes designed for your specific workflow, i think it's best for you to code it yourself in your branch, we can merge it when it's stable (and if it won't clutter the gui too much). We can help you getting started.

But it may be better to wait for the gui stuff to be moved into c++ before. @lordofhyphens ?

[jammi]

The hardest thing to PoC this would be to include a surface texture image selection option to the Printer → General → Bed section. Then it'd need rendering the contents of that image as the bed surface texture. Lastly, it'd need checking if the file is changed and reload and re-render, if it is.

The rest could be done by external means such as an OctoPrint plugin and somehow fetching that image to the Slic3r machine in case they're separate (my hunch of the 80/20 says they usually are).

[supermerill]

The hardest thing to PoC this would be to include a surface texture image selection option to the Printer → General → Bed section. Then it'd need rendering the contents of that image as the bed surface texture. Lastly, it'd need checking if the file is changed and reload and re-render, if it is.

you can try to use the commit from slic3rPE where they added their surface bed image.

[lordofhyphens]

It is feasible to update the bed draw code to put a texture on the bed plane.

[ledvinap]

IMO this can be all emulated outside slic3r. Only bed texture is necessary ...

Postprocessing script can generate picture with first layer and blend it with current state ...

[jammi]

@ledvinap Yes, I agree. At least for a PoC that'd be feasible as long as there's bed texture support in slic3r itself.

@lordofhyphens Would it be feasible to implement so that it either looks for a file defined in the printer config, or something based on the printer settings profile name?

[lordofhyphens]

I am unwilling to implement pointers like that for security reasons. People tend to share config files and external files like that are rife for abuse

[jammi]

@lordofhyphens Ok, so what do you suggest as an alternative to it?

[lordofhyphens]

@jammi I was mentally over in another issue.