FeatureRequest: Recognize correct Bed type for given filament and warn if wrong (also set "Live Z adjust")

[puterboy]

I'm sure you are tired of my suggestions by now :)... but here is an idea...

One problem that I have more often than I wish to admit is that I either:

• Forget to change the bed type when changing filament type (e.g., for Prusa, I use the smooth PEI plate for PLA but Satin for PETG, ASA and PC Blend)
• Change the bed but forget to change the "Live Z-Level Adjust" for the new bed Both of the above have the potential (and the reality) to damage expensive beds if forgotten.

So, assuming your plugin can distinguish between bed types either by:

• Color/texture/native markings on the plate
• If necessary, user-added markings, say by sticker or Sharpie

Then, logic for the modified plugin would be as follows:

1. Read the filament type from the G-Code (Prusa Slicer for sure adds several filament-related lines, including "filament_settings_id")
2. Identify the plate based on Camera/AI (guts of your current plugin)
3. Look up the pair in a table of (new) Plugin settings variables that would match filament type to desired bed type. The table would also contain the desired "Live adjust Z" for each bed type.
4. Check to make sure the "Live adjust Z" level is set correctly for the current plate -- if not possible to read the "Live adjust Z" level with G-code, then perhaps have user set the Z-level to some fixed number (even 0) and then use G92 to add a bed-specific adjustment for each bed in the table

Based on this logic:

• User would never use the wrong plate
• User would never forget to set the "Live adjust Z" level

If you have already created the camera AI/identification routines, it seems like you have already done the hard part...

[jneilliii]

#4 should technically be done in your slicer, specific to filament start gcode. The matching of different types of bed to filament identifiers is something I'd consider implementing though as it is inline with multiple matches requested by others. It's just an extension of that concept.

[puterboy]

Thanks/

4 is not about different filaments but about different plates and the slicer has no knowledge of what plate you are using. For example, my Prusa Satin PEI plate needs the nozzle to be about 0.2mm lower than my PEI plate - presumably it is 0.2mm thinner.

The Prusa MK3S+ can store the adjustment for up to 8 different plates - however, one must remember to dial in this change every time you change plates.

However, if you can recognize the plate automatically, you should be able to either change the setting on the printer or failing that add a uniform adjustment to the G-code using G92.

In Prusa speak, a "-1500" LIve adjust Z adjustment means move the nozzle 0.15mm closer to the bed.

[RoboMagus]

I have an open PR on the Prusa Firmware repo that adds GCode to verify the steel sheet the printer currently thinks is installed.

I too often run my nozzles in the steel sheet because I forget to switch the sheet or update the setting in the printer. How I envisioned a solution is to write an Octoprint plugin that matches filament types with specific Steel Sheets. Then at startup we could query the printer to check if the steel sheet matches. The user can then be warned if expectations are not met by pausing the print and showing a message on its LCD and / or send a notification through Octoprint.

Relying on image matching for the small differences between steel sheets is IMO very unlikely to succeed as there are much more significant differences introduced by lighting, slight change in position, etc.

[RoboMagus]

@puterboy, seeing as the printer already stores the steel sheet profiles for you, you should never have to manually change the live adjust z value when the sheets have been properly calibrated. We just need to remember to update the Active Sheet through the printer menu when actually swapping the sheets.

[puterboy]

Relying on image matching for the small differences between steel sheets is IMO very unlikely to succeed as there are much more significant differences introduced by lighting, slight change in position, etc.

As I mentioned in my original post, one could easily mark the sheet in a distinctive way -- whether an indelible marker or even some purposeful scratchings outside the print border. It should not be hard at all to create somethingdistinctive that even the simplest AI could detect.

[puterboy]

@puterboy, seeing as the printer already stores the steel sheet profiles for you, you should never have to manually change the live adjust z value when the sheets have been properly calibrated. We just need to remember to update the Active Sheet through the printer menu when actually swapping the sheets.

But that's my point - I often forget to update the Active Sheet. So unless there is a G-code to do that, the next best thing would be to change the G-code in the print file automatically.

[RoboMagus]

... somethingdistinctive that even the simplest AI could detect.

This plugin doesn't use an AI though. Just simple image matching. So implementing something like that would be a huge change.

[puterboy]

What if you painted a different number/color of dots on the out-of-boundary edges of the different plates. Surely that could match

[RoboMagus]

I'm sceptical about its succes-rate, and it really feels like a separate plugin, but I'm not the author of this one and just speculating.

@jneilliii would have to weigh in on that.

[jneilliii]

I agree with @RoboMagus that this change wouldn't be an easy one. I have next to zero knowledge when it comes to AI and training models, but my thought was to potentially loop through a set of registered images with the simple image matching approach I'm currently using. Then based on the highest percentage match use that to identify which additional commands to run prior to continuing the print. If no matches are over a given threshold then you get the prompt. This approach would require validating if the different beds could be identified differently through some means, be it painted identifiers or the like, and ideally would benefit from the ability to mask/pick regions in the image for comparison (which was already something I wanted to do with the current implementation anyway).

Based on that, I think my next changes will be figuring out the masking bits for easier identification prior to expanding it to matching multiple images.

[puterboy]

Perhaps there could be a barcode or simplified barcode equivalent that one could to each plate to improve matching.

[jneilliii]

Yes, I would lean towards QR Codes in this instance as opencv does include QRCodeDetector().detectAndDecode(img) and probably can see those easier, but again not something that is going to happen anytime soon. It could potentially be done faster as a separate plugin using the above method, which I found in a quick Google search that landed me here.

[puterboy]

Interesting link! I would suggest Micro QR as they take up much less space (and we don't need to store much data - just an ID