PrintVault Pro — Smart 3D Printer Enclosure

This page is the place where everything I learned across Fab Academy 2026 comes together. Almost every weekly assignment contributed a concrete piece of this machine, so throughout the text I link back to the specific week where I developed each skill. If you want to see how a particular subsystem was learned and tested in isolation, follow those links.

In one sentence: PrintVault Pro is a smart, heated enclosure for an FDM 3D printer that holds the right chamber temperature for each material, watches the print with a camera and an edge AI model, and warns the user the moment a "spaghetti" failure begins — locally, on a desktop app, and on their phone.

Problem

Many 3D printing materials are sensitive to drafts, ambient temperature changes, and humidity. ABS and ASA warp and crack when the chamber is cold; Nylon and Polycarbonate need even higher, stable chamber temperatures to avoid layer separation. Beyond materials, the most expensive failures happen mid-print: a part detaches, the nozzle drags filament into the air and produces the classic "spaghetti" failure. An 8-hour print can be ruined in the first 20 minutes, and unless somebody is watching, the printer keeps extruding plastic into nothing — wasting filament, time, and in the worst case becoming a safety risk.

I measured this problem directly in my Week 16 (Wildcard) work: a single undetected spaghetti failure turned a part that should have weighed ~14 g into a tangled mass of wasted filament. That experiment is what motivated building the AI detection into the final enclosure rather than treating it as a separate demo.

Who has done this before? (prior art)

Both halves of this project build on existing work, and looking at it shaped my design decisions:

• Heated enclosures: commercial printers like the Bambu Lab X1 and the Stratasys industrial machines ship with heated, enclosed chambers precisely because ABS/ASA/PC need a controlled environment. Aftermarket enclosures (e.g. Creality/“tent”-style enclosures) exist too, but most are passive — they trap heat from the printer instead of actively controlling it. PrintVault Pro differs by adding active, closed-loop heating with per-material setpoints.
• Camera-based print monitoring: automated camera monitoring of additive manufacturing dates back to at least 2016 (Everton et al., Materials & Design). On the consumer side, the best-known prior work is The Spaghetti Detective / Obico, an open-source AI failure-detection project, and Bambu’s own built-in AI detection. Most of these run detection in the cloud or on the printer’s own electronics.
• What I do differently: PrintVault Pro runs the detection entirely on the edge (a Raspberry Pi 5, no cloud, no subscription) and combines it with active environmental control and a multi-channel alert system in a single self-built enclosure. The novelty is the integration, not any one block in isolation.

Solution

PrintVault Pro attacks both problems at once. A heated, sensor-monitored enclosure keeps the chamber at the right temperature for each material with closed-loop hysteresis control, while a camera + YOLO model running on a Raspberry Pi 5 supervises the print in real time. When a failure is confirmed, the system raises an alert on the local OLED display, in the desktop app (pop-up), over MQTT for home-automation integration, and as a push notification to the user's phone via ntfy. Everything is controllable remotely from a PyQt6 desktop application over WiFi.

Core features

• Closed-loop chamber heating: a 100 W 12 V PTC heater driven by a MOSFET, controlled with hysteresis around a per-material setpoint (PLA 25 °C → PC 55 °C). Developed in Week 10 (Output Devices).
• Active ventilation: a 12 V fan for cooling, fume management, and emergency heat dissipation.
• Temperature & humidity sensing: Sensirion SHT31 over I²C, sampled every second, with a fault-tolerant watchdog. Developed in Week 9 (Input Devices).
• Local status display: 1.3" SH1106 OLED showing live T/H, mode, setpoint, actuator states and connection status.
• AI print monitoring: a YOLO model detects spaghetti failures on the live camera feed; alerts require 3 seconds of continuous detection to suppress false positives. Developed in Week 16 (Wildcard).
• Multi-channel alerts: desktop pop-up, MQTT topic, and ntfy push notification to the phone. Built on the protocols explored in Week 11 (Networking & Communications).
• Remote control: PyQt6 desktop app (packaged as a Windows .exe with PyInstaller) with live annotated video, material presets, AUTO/MANUAL modes and emergency stop. Developed in Week 14 (Interface & Application Programming).
• Multi-layer safety: hard over-temperature cutoff, sensor watchdog, and heater shutdown on connection loss — all independent of the network.

System architecture

Click to view assignment:

The system is split into three layers, each doing what it is best at. The data flow is:

Desktop App ⟷ WiFi (WebSocket + HTTP) ⟷ Raspberry Pi 5 ⟷ BLE ⟷ XIAO ESP32-S3 ⟷ sensors & actuators

• XIAO ESP32-S3 (firmware, C++/Arduino): the real-time layer. It owns the sensors and actuators and runs the control + safety logic locally, so the enclosure remains safe even if WiFi, the Pi, or the app go down. It exposes a BLE Nordic UART Service (NUS). The embedded programming behind this comes from Week 4 (Embedded Programming).
• Raspberry Pi 5 (gateway, Python/FastAPI): the intelligence layer. A single process bridges BLE ⟷ WebSocket, runs YOLO inference on the CSI camera, streams the annotated video as MJPEG, and dispatches notifications (MQTT + ntfy). It runs as a systemd service, so it starts automatically on power-up.
• PyQt6 desktop app (Python): the user layer. It connects to the Pi over WiFi only — it never talks BLE directly — which means it can run on any computer on the network (or remotely via Tailscale).

Why a gateway instead of direct BLE to the app? Three reasons. First, range: BLE limits the user to ~10 m from the enclosure, while WiFi (and Tailscale) allows control from anywhere. Second, the camera: the CSI camera physically connects to the Pi, so video has to flow through it anyway. Third, the AI: YOLO inference needs the Pi's CPU — the ESP32 can't run it. Centralizing everything in the Pi means the app only needs one connection to get state, video, and alerts.

Electronics & hardware design

Click to view assignments:

The control electronics are built around the Seeed Studio XIAO ESP32-S3. Both loads (heater and fan) are low-side switched with logic-level N-channel MOSFETs, driven directly from GPIO pins. The reasoning behind the MOSFET driver stages — gate resistors, pull-downs and flyback protection — is the same one I worked out in detail in Week 10 (Output Devices):

The individual circuit blocks that make up this board were each designed and tested as separate weekly assignments, and then combined onto the single custom PCB. Below is where each part of the electronics was developed:

• Heater driver (MOSFET output stage): the heater's MOSFET driver — gate resistor, pull-down and the output-switching design — was developed and tested in Week 10 (Output Devices), where I also documented the heater PCB/driver design.
• XIAO ESP32-S3 board (controller + I²C): the controller board around the XIAO ESP32-S3, with its I²C headers for the SHT31 and OLED, was designed and milled/soldered in Week 8 (Electronics Production).
• Fan driver: the fan's MOSFET driver stage use the same design principles as the heater driver, it only have 1 more cable that is used for the tachometer.

The fabrication process for the fan driver PCB was the same as the one of the Week 8 (Electronics Production).

The choice of a PTC heater (instead of resistance wire or heater cartridges) is deliberate: PTC elements increase their resistance as they heat up, so their power output self-limits — even in a worst-case electronics failure they cannot reach ignition temperatures the way nichrome wire can. The SHT31 was chosen over the common DHT11/DHT22 because it is a true I²C device with ±0.2 °C accuracy and much better long-term reliability — and accuracy matters when the control hysteresis band is only ±2 °C. I validated this sensor and its I²C bus first in Week 9 (Input Devices).

Firmware (XIAO ESP32-S3)

Click to view assignment:

The firmware is a single non-blocking loop (no delay()-based logic) that every cycle: reads the sensor (1 Hz), runs the safety + control logic, applies outputs, and publishes the state over BLE (1 Hz) while refreshing the OLED. The non-blocking structure and the BLE stack build directly on what I learned in Week 11 (Networking & Communications). Communication uses the Nordic UART Service (NUS) profile: a Write characteristic (RX) receives newline-terminated text commands, and a Notify characteristic (TX) pushes one JSON state line per second:

{"t":32.4,"h":38,"heater":1,"fan":0,
 "mode":"AUTO","sp":45,"status":"NORMAL"}

In AUTO mode the heater is governed by hysteresis control: it turns on below setpoint − 2 °C and off above setpoint + 2 °C; inside the band it keeps its previous state. This avoids the rapid on/off relay-chatter a simple threshold would cause, which matters for MOSFET/heater longevity. A PID loop was considered, but a thermal chamber is a slow, heavily damped system — hysteresis reaches the same steady state with one tunable parameter instead of three.

Safety design

Safety logic runs every loop iteration, before anything else, and independently of connectivity. The layers, in order of evaluation:

• Sensor watchdog: the SHT31 occasionally returns NaN glitches. A single bad reading does not kill the heater — the firmware tolerates up to 3 consecutive failures while holding the last valid value. But if failures persist, or no valid reading arrives for 5 seconds, the sensor is declared dead and the heater is forced off. Rationale: a heater running blind is the single most dangerous state of the system.
• Hard over-temperature cutoff: at ≥ 65 °C the heater is cut and the fan is forced on, regardless of mode, setpoint, or any command. The user-settable setpoint is capped at 60 °C, leaving a 5 °C guard band below the hard limit.
• Early warning: within 5 °C of the hard limit, the reported status changes to WARN so the app and OLED show it before a cutoff happens.
• Connection-loss policy: if BLE drops while in MANUAL mode, the heater is switched off — a heater left on manually must never keep running unsupervised. AUTO mode survives a disconnection because the closed loop keeps it safe.
• Safe boot: all output pins are driven LOW before anything else in setup(), so a brown-out reboot can never leave a load energized by accident.

Raspberry Pi gateway

The gateway (pi_gateway.py) merges what used to be separate scripts into one FastAPI process, for a hardware reason: the CSI camera can only be opened by one process at a time, and both the AI detector and the video stream need its frames. Running them in one process means the MJPEG stream serves the exact frame YOLO annotated — the user sees precisely what the AI sees, bounding boxes included.

Internally the process runs three concurrent units: the BLE bridge (asyncio task using Bleak, with automatic scan-and-reconnect every 5 s if the XIAO disappears), the detector (a dedicated OS thread, because camera capture and YOLO inference are blocking operations that would freeze the asyncio event loop), and the FastAPI/uvicorn server. The thread hands frames and alerts back to the async world with asyncio.run_coroutine_threadsafe, and the MJPEG generator blocks on a condition variable so it serves frames at exactly the rate the detector produces them — no busy-waiting, no duplicated frames.

How I configured the gateway (systemd auto-start)

I wanted the whole system to come up on its own whenever the Raspberry Pi is powered — no terminal, no manual command — so I set up the gateway as a systemd service. These are the steps I followed:

1. Placed the code and model together: I put pi_gateway.py and the YOLO weights (best.pt) in the same working folder on the Pi, so the service can find the model with a relative path.
2. Installed the Python dependencies: FastAPI, uvicorn, Bleak, Ultralytics YOLO, Picamera2 and OpenCV, so the script runs outside any virtual environment the service would have to activate.
3. Created a unit file at /etc/systemd/system/fab-gateway.service describing how to run the gateway:

   [Unit]
   Description=PrintVault Pro gateway (BLE + AI + web)
   After=bluetooth.target network-online.target
   Wants=network-online.target
   
   [Service]
   User=zarten28
   WorkingDirectory=/home/zarten28/best_ncnn_model
   ExecStart=/usr/bin/python3 /home/zarten28/best_ncnn_model/pi_gateway.py
   Restart=always
   RestartSec=3
   
   [Install]
   WantedBy=multi-user.target

4. Key options and why:
   • After=bluetooth.target — makes systemd wait until BlueZ (the Bluetooth stack) is ready before the gateway starts scanning for the XIAO, so the first BLE scan doesn't fail.
   • WorkingDirectory — set to the folder with best.pt so the YOLO weights resolve correctly.
   • Restart=always with RestartSec=3 — if any component crashes (a camera glitch, a BLE hiccup), systemd relaunches the process automatically after 3 s.
5. Enabled and started the service:

   sudo systemctl daemon-reload
   sudo systemctl enable fab-gateway.service
   sudo systemctl start fab-gateway.service

   enable makes it start automatically on every boot, and start launches it immediately.
6. Checked it was healthy: I used sudo systemctl status fab-gateway.service to confirm it was running, and opened the /health endpoint in a browser to verify the BLE link and the AI were up.

The result is exactly what I wanted for a final project: plugging in the Raspberry Pi is enough to bring the entire gateway (BLE bridge, AI detector and web server) online in under a minute, with no manual steps and automatic recovery from crashes.

AI print monitoring

Click to view assignment:

Failure detection uses a YOLO object-detection model trained to recognize the "spaghetti" failure pattern, running entirely on the Raspberry Pi 5 (edge inference, no cloud). This is the heart of my Wildcard work — the full development of the computer-vision model (dataset, training, evaluation and deployment) is documented in detail in Week 16 (Wildcard — Computer Vision). Here is how that model was built and how it works, and why each decision was made:

• Dataset (design + cleaning): I started from public 3D-printing-defect datasets on Roboflow, then cleaned them — removing visually similar classes (zits, stringing, blobs) and keeping only spaghetti — because those extra classes were the main source of false positives. Full process in Week 16.
• Model + training: I trained a YOLOv11n model (the "nano" variant) with transfer learning, tuning epochs, image size, batch size and confidence, and disabling aggressive augmentations (mosaic) that were generating false detections. YOLOv11n was chosen for its low computational load so it can run on the Pi 5's CPU.
• Evaluation: the final model was validated with a confusion matrix that reached 0.94 for spaghetti and 0.96 for background — a big improvement over the first noisy attempts. The evaluation curves are in Week 16.
• Capture: Picamera2 grabs frames at 640×480 RGB from the CSI camera.
• Preprocessing: frames are converted to grayscale and expanded back to 3 channels. This makes detection robust to filament color and chamber-light color — spaghetti is recognized by shape and texture, not color — and matches how the model was trained.
• Inference: 320 px input size. The reduced input size keeps inference fast enough for continuous monitoring on the Pi; spaghetti is a large, distinctive pattern, so small-object resolution is not needed.
• Temporal confirmation: a detection must persist for 3 continuous seconds before an alert fires. Single-frame false positives (a hand passing by, a lighting flicker, a glare) never trigger anything.
• Cooldown: after an alert, external notifications are suppressed for a while so one failure produces one notification, not a phone-buzzing flood.

The key difference between the Wildcard demo and the final project is integration: in Week 16 the model ran as a standalone detector, while here the same trained best.pt runs inside the Pi gateway, so its detections drive the enclosure's multi-channel alert system (desktop, MQTT, phone) instead of just printing to a screen.

When a failure is confirmed, the alert fans out over three channels simultaneously: a WebSocket message the desktop app turns into a pop-up and a red status, an MQTT publish on impresora/errores/spaghetti (ready for Home Assistant or any other automation), and an ntfy push notification that reaches the user's phone even when they are away from the computer. The MQTT and BLE/WiFi messaging here is the practical payoff of the protocol comparison I did in Week 11 (Networking & Communications).

Desktop application

Click to view assignment:

The control app is built with PyQt6, and is the direct continuation of the interface I developed in Week 14 (Interface & Application Programming) — that week is where the GUI, its layout and its logic were first designed and documented. The UI layout was designed in Qt Designer and compiled with pyuic6 (frontendFAB.py); the logic lives in backendFAB.py. Because PyQt's event loop and Python's asyncio loop don't normally coexist, the app uses qasync to merge them — the WebSocket client and the health monitor run as asyncio tasks inside the Qt application without blocking the UI.

• WebSocket client: receives the 1 Hz state JSON and the AI messages, and queues outgoing commands. It reconnects automatically every 3 s if the link drops.
• MJPEG viewer: a QThread reads the raw HTTP stream, finds JPEG frame boundaries (FFD8…FFD9 markers) in the byte stream, and emits each frame as a QImage scaled into the camera panel.
• Health monitor: polls /health every 5 s, so the sidebar distinguishes three situations: Pi offline, Pi online but XIAO unreachable over BLE, and everything connected.
• Material presets: selecting a material (PLA, PETG, ABS, ASA, TPU, Nylon, PC) automatically sends the right chamber setpoint; "Custom" unlocks the spinbox for free adjustment.
• State reconciliation: the UI never trusts itself — every indicator is corrected by the state the XIAO actually reports, so the app always reflects physical reality, not the last button pressed.
• Distribution: the app is packaged with PyInstaller (--onefile --windowed) into a standalone Windows executable, so it runs on any PC without a Python installation.

How it was made — Fab Academy processes

PrintVault Pro was built almost entirely with the digital-fabrication and electronics processes learned during the Fab Academy weekly assignments. Every major subsystem of the enclosure maps to a skill area from the course, and each heading below links to the week where I first learned and documented that process:

Sheet metal chassis (cutting and bending)

The main body of the enclosure is made of sheet metal. The panels were cut to size with an angle grinder and then bent on a sheet-metal hand folding machine to form the structural chassis. Metal was chosen over wood or acrylic for the body because the chamber runs at up to 55–60 °C with a 100 W heater inside: metal is non-flammable, dimensionally stable at those temperatures, and acts as a thermal mass that helps the hysteresis control hold a steady temperature.

Laser cutting (computer-controlled cutting)

The doors are laser-cut acrylic, using the computer-controlled cutting workflow from Week 3 (Computer Controlled Cutting). Acrylic was selected for the doors for two reasons: the user needs to see the print without opening the chamber (every door opening drops the chamber temperature and risks warping), and the camera/AI benefit from a closed, draft-free environment. The door outlines, hinge mounting holes and handle holes were drawn in CAD and cut on the laser, so the holes line up exactly with the 3D-printed hinges and handles with no manual drilling.

3D printing (additive manufacturing)

Click to view assignment:

All the custom mechanical hardware was 3D printed in ABS, applying the design rules and slicing workflow from Week 5 (3D Scanning & Printing). Each part below was designed specifically for this enclosure:

• Enclosure for the custom PCBs — protects the electronics and keeps wiring organized in the electronics compartment.
• Case for the power supply — encloses the 12 V PSU so its mains/12 V terminals are covered and it mounts cleanly to the chassis.
• Case for the Raspberry Pi 5 — with ventilation, since the Pi runs continuous YOLO inference and needs airflow. (Get from MakerWorld)
• Door handles — printed to fit the laser-cut holes in the acrylic.
• Hinges — custom printed hinges joining the acrylic doors to the metal chassis. Made in Week 5 (3D Scanning & Printing)

These are the CAD designs of the new printed parts made specifically for the enclosure:

❮ ❯ 1 / 5

❮ ❯ 1 / 15

❮ ❯ 1 / 6

ABS was a deliberate material choice, not a default: with a glass transition around 105 °C, it withstands the chamber's operating temperature with a wide margin, while PLA (T_g ≈ 60 °C) would soften and creep on parts mounted near or inside a 55 °C chamber. Fittingly, printing reliable ABS parts is exactly the kind of job the finished enclosure makes easier — the project's own parts justify the project.

Mechanical design

The enclosure is designed around airflow, thermal stability, and serviceability:

• Bent sheet-metal chassis: non-flammable, rigid, and thermally stable at chamber temperature; flanged bends seal the box better than bolted corners.
• Laser-cut acrylic doors with 3D-printed ABS hinges and handles, so the print is visible without opening the chamber and losing heat.
• The PTC heater is mounted away from printed/plastic parts, with metal standoffs and a guard, so radiant heat cannot reach anything meltable.
• The fan is positioned for exhaust so it can both regulate temperature in normal operation and dump heat fast during an emergency stop.
• The camera is mounted with a clear, fixed view of the build plate — a stable framing is important for the AI, since the model sees a consistent background.
• Electronics (custom PCB in its ABS case, Raspberry Pi 5 in its ventilated ABS case, power conversion) live in a separate compartment outside the heated volume — the chamber can reach 55–60 °C, which is hostile to electronics, and the Pi needs cool air for sustained YOLO inference.

Final assembly

Once all the parts were ready — the bent sheet-metal chassis, the laser-cut acrylic doors, the 3D-printed hinges, handles and cases, and the electronics — everything was brought together into the final assembled enclosure. This is where the mechanical design proves itself: the printed hinges align with the laser-cut holes, the doors close against the chassis, and the electronics sit in their own compartment. The media below shows the complete assembly.

Testing, validation & evaluation — how was it evaluated?

The project was evaluated against the requirements it was designed to meet: hold temperature, stay safe, and catch a failure. Each subsystem was tested deliberately rather than just:

• Thermal loop: verified that the chamber reaches and holds each material setpoint within the ±2 °C hysteresis band, and that the 65 °C hard cutoff fires with the heater forced on manually.
• Sensor watchdog: validated by disconnecting the SHT31 mid-operation — heater cut off within the 5 s timeout; serial diagnostics log every NaN reading and every heater state transition with the reason.
• AI detection: evaluated quantitatively with a confusion matrix that reached 0.94 for spaghetti and 0.96 for background (seeWeek 16), and qualitatively with provoked spaghetti failures; the 3-second confirmation eliminated false alerts from hands and lighting changes during normal use.
• Recovery: power-cycled the Pi (systemd brings the gateway back automatically), rebooted the XIAO (BLE bridge re-scans and reconnects), and killed the app (WebSocket reconnects on relaunch) — the system recovers from each failure without manual intervention.

Video from the testing session: