Reality Check - an OctoPrint plugin to stop me from using the wrong filament

Yesterday, and not for the first time, I used the wrong filament for a print.
My printer is a Prusa Core One Plus, and it can handle one filament at a time. I mainly alternate between printing two types of things:

1. Small figurines I find on Thingiverse
   These I print with PLA, of which I have several colors and styles
2. Stupid engineering prototypes, including things that go on the printer
   For these I use PETG, which is more resistant to high temperatures (PLA gets soft at 60°C)

Those materials differ in how the printer handles them. Specifically, each one has a different nozzle temperature (how hot the printhead needs to get for the material to melt) and bed temperature (what temperature the surface I print on needs to keep the material solid, but still adherent). The program that converts models to printing instructions, called a slicer, takes the type of material I want to use as a parameter, and based on that parameter codifies into the print instructions the different temperatures, amongst other things (e.g. the movement speed of the printhead).

Yesterday I was experimenting with a new printcam mount, which is a PETG contraption holding a small camera in the corner of the printer, so I can see how prints are going.

For this, I was printing, tweaking, and printing again some parts in PETG.
While doing some tweaking for the models on the computer, I put the printer to work on a SC2 Thor model I found. It’s made of multiple parts and can move some of its appendages, and I like it very much. This was printed in PLA, as it doesn’t need to stand weird temperatures, but it does need to look pretty

When I went back to printing my camera mount, I remembered to switch the printer’s filament to PETG (my PETG is boring black, very differentiable from the stunning blue of the Thor’s PLA), but I forgot to change the slicer’s filament setting, so the instructions were written assuming PLA.

While the models started to print just fine, they would lose their grip mid-print, causing the printer to extrude “spaghetti” in the air instead of adding layers to the model, ruining the print and sometimes accumulating print material on the printhead. I started with blaming myself with putting my greasy fingers all over the print surface, ruining its adhesion with my skin oils. It got an IPA wipe, and when that didn’t help it went to the sink for some dish soap. When that didn’t work, I got a bit confused and tried thinking what changed from the morning, when everything worked perfectly.

Luckily, the slicing software names its files with all kinds of metadata, and I noticed the file was called b0471-adapter-v9_0.4n_0.15mm_PLA_COREONE_50m.gcode. Sharper eyes can see that the file contains “PLA” and not “PETG”, while the material being printed was PETG. This explained the problem.

The PLA nozzle temp luckily is in range of PETG’s melt temp, although it probably was more gloopy than the printer would have liked, and the bed temperature for PLA isn’t hot enough to keep PETG sticky, which explains why the models were so keen to leave midprint.
Obviously I resliced the model (b0471-adapter-v9_0.4n_0.15mm_PETG_COREONE_58m.gcode for the win) and got on with my testing, but it left me frustrated. “This could have been avoided”, I thought.

It knows already

When I swap filaments in the printer, it asks me what kind of filament it has now. It needs to know in order to warm up the hotend and ensure it can pull it through. It also remembers this info because it shows it on its tiny screen when printing

As I suspected, the file also specifies which filament it wants. gcode files are text, and they have a sort of frontmatter that contains this:

; filament_type = PLA

So the printer could say “You want to print PLA but I have PETG. This is probably a bad idea”.
Turns out it does - Prusa firmware, when asked to print a file from local storage or network, already does that check and stops you from printing the wrong material

if (report.failed(buddy::gcode_compatibility::VirtualToolCheck::filament_type)) {
    return State::wrong_filament_wait_user;
}

(Source: src/common/marlin_print_preview.cpp)

My problem was that I was not printing from local storage, but rather over USB (“serial connection”) from my OctoPrint instance.
Any printer that prints from serial never sees the file metadata that contains the filament type - it only gets “go there do that” instructions, so it can’t run the check for mismatches.
OctoPrint becomes the only entity that sees both the file and the printer, and therefore the only one that can prevent those moments of stupidity from translating into bad prints.
It also has plugins, which means I don’t have to fork OctoPrint to get the change I wanted.

Cruising through the plugin repository and the forum, the closest match I found was SpoolManager which does something similar, but wants you to maintain which filament you’re currently holding, meaning that instead of taking updating off my hands, it adds another layer.

Instead, I looked through Prusa’s BuddyBoard firmware and picked up command M865 that lets me read (or write) the filament currently loaded to the printer. This meant I can have a plugin read the filament type from the file, read the one from the printer, and stop any foolish attempts to print when the two aren’t equal

The result

Reality Check does exactly that.

It can be installed from OctoPrint’s Plugin Manager:
Get More…, …from URL, then https://github.com/BackSlasher/OctoPrint-Reality-Check/archive/main.zip.
I’d put it on the OctoPrint plugin gallery but they don’t allow vibecoded plugins, which is fully understandable.

It queries the printer for what it has (filament and nozzle specs), and when a print starts, it scans the file for that expected configuration metadata. If it finds a discrepancy, it blocks the print and shows a popup. The part I like best about it is that there’s no extra maintenance to be done - Prusa’s Slicer already emits the file metadata I need, and the printer itself already has a gcode to query for its inventory. For someone whose original problem was not remembering to update configs, this is perfect.

I added support for nozzles despite me only having one kind, because the data was readily accessible in the files and the printer.

Interesting implementation quirks:

1. Because of the way OctoPrint implements “print blockers”, I couldn’t ask the printer at real-time for its inventory. The blocker gate is at “start sending gcode to the printer”, which blocks the serial write thread. This means that inside the block, I can’t initiate any serial writes.
   Instead, I query the printer every 30s (configurable) when idling, and use the last value at the moment of truth. As long as someone can’t change a tool in under 30s (I can’t on my printer), I’ll be up to date.
   As a side effect, knowing the printer’s values at all times lets me show them in a tab

   

2. I support a more relaxed mode, where I only care when the file explicitly asks for something, and the printer explicitly reports something, and the values mismatch. Empty values (printer doesn’t report, file doesn’t say) pass. I also added a “paranoid mode” which I now use that complains on empty values as well.
   
3. There is no true concept of RPC in OctoPrint’s codebase (where I ask a question, block until I get the answer, let the serial get back to its business). Instead, we have some hacky helper methods that track which question we asked (e.g. M865 which is “which filament do you have”) and fish out the one line we expect using regex. Not perfect, but robust enough for this case.

Claude helped

I leaned heavily on Claude on this one. It did both the footwork in the Buddyboard firmware to discover the gcodes and their format response, the coding of the actual plugin, and deployment and testing on my OctoPrint instance.
I mainly “directed” it, and I’m very happy with its performance here. ~1.5h of laptop time, and I scratched this itch, probably for good.