Live lab telemetry
The print lab, in real time.
An automated pipeline transforming custom Shopify orders into production-ready 3D prints via Python and Blender-MCP. This dashboard displays live, 30-second telemetry from the active Creality K2+ and Bambu P1S print farm.
Production pipeline
Order-to-print architecture
Order-to-print workflow spanning custom Shopify integration, Python orchestration, Blender-MCP geometry, multi-material 3D modeling (3MF), and dual-track dispatch across Creality K2+ and Bambu P1S farms. Live telemetry posts every 30 seconds to dashboards.
Engineering rationale
Technical decisions
Why this stack, what the trade-offs were.
Why two separate printer tracks (K2 + Bambu)?
Different guarantees. K2 is open-source, local, and dev-friendly — I can mod it, read logs, script scheduling. Bambu is cloud-connected, locked down, and comes with commercial warranty. K2 handles prototype iterations and one-offs. Bambu handles larger orders where warranty coverage and support matter. This dual-track setup leverages open-source flexibility for development while protecting hardware warranties on volume runs.
Why Potrace + Blender instead of vectorizing in the slicer?
Slicers don't vectorize well. Potrace gives me clean, editable SVG curves from raster uploads. Blender-MCP lets me programmatically compose those curves into 3D geometry — extrude text to depth, add bevels, embed SVG into complex assemblies. The alternative is manual tracing in Inkscape for every custom order, which doesn't scale.
Why 3MF instead of STL?
3MF preserves material data: color, texture, per-face material assignments for AMS/CFS (Bambu's multi-material system). STL throws away everything but geometry. For orders with color or multi-material specs, 3MF is the only format that carries the intent from the CAD model to the printer.
Why manual gate on Bambu but auto-dispatch on K2?
Warranty. Bambu Studio expects human review before print — that's their standard workflow and it's part of the support contract. K2's open architecture lets me fully automate the queue.
Why telemetry every 30s instead of real-time?
Moonraker and Bambu APIs have request budgets. 30s is a balance between responsiveness (users see status updates under a minute) and respect for printer APIs (I'm not hammering them). At 2–3 concurrent prints, 30s is plenty to catch thermal issues or jam signals.