Live lab telemetry
The print lab, in real time.
Two Bambu P1S and one Creality K2+ running in a Florida apartment, polled every 30 seconds by a local Python agent and pushed to this page. K2+ uses Moonraker API. P1S units connected via Farm Manager.
No telemetry yet.
The local agent posts here every 30 seconds when it's running. If you're seeing this, it hasn't checked in yet — the page will populate the moment it does, without a redeploy.
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 — we 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. Dual-track lets us optimize each job for the right machine.
Why Potrace + Blender instead of vectorizing in the slicer?
Slicers don't vectorize well. Potrace gives us clean, editable SVG curves from raster uploads. Blender-MCP lets us 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 us fully automate the queue. If we skipped the human gate on Bambu, we'd lose support coverage for failed prints.
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 (we're not hammering them). At 2–3 concurrent prints, 30s is plenty to catch thermal issues or jam signals.