Digital fabrication

:::caution Experimental module

Digital Fabrication ships as Experimental (it wears an amber Experimental badge inside Cobblr). Everything on this page is real and in daily use, but the module is not yet promised stable, so its behaviour and shape can still change between releases. An instance started with COBBLR_DISABLE_EXPERIMENTAL_MODULES=true skips experimental modules entirely, so there Digital Fabrication will not appear at all.

:::

Digital fabrication (digifab) is the side that actually makes things: it sends a file to a machine to be made and tracks the job to completion, across one printer or a farm of them.

The loop:

1. Connect a machine (or a manager like OctoPrint or FDM Monster).
2. Drop a 3MF or gcode file into the library.
3. Send it as a new job to a machine, a pool, or a tag, and confirm. Cobblr tracks the print to completion.
4. Clear the bed with a verdict: Came out good or Scrapped.

Coordinate, not control

Cobblr hands a machine a file and follows the job. The machine's own controller, not Cobblr, drives the hardware move by move.

• Machines with their own API (Duet, Klipper): Cobblr talks to them directly, nothing in between.
• Machines with no API (a Marlin printer): something in front gives them one, usually OctoPrint, and Cobblr talks to that.
• Bambu printers: over Bambu's cloud, Cobblr can watch, pause, and stop jobs, but Bambu blocks third parties from starting prints, so sending a job needs the printer's LAN access through the edge bridge.

How Cobblr reaches a machine

• Self-hosted on the same network as your machines: Cobblr reaches them directly. Nothing else to run.
• A firewall between Cobblr and the machines, or machines at a different site (a second workshop, say): run the edge bridge where the machines are, and Cobblr connects through it. The bridge always dials outward, so nothing on your network is exposed.
• Software pinned to one computer, like LightBurn: even on the same network, Cobblr has to drive it on the PC it runs on, so the bridge runs there.

How the edge tunnel works, and remote cameras

An instance away from your workshop reaches a printer behind your router the same way: an edge agent on the machines' network dials out and holds the line open, so Cobblr can list, upload, print, pause, and track as if the printer were local, with no port-forwarding. Point an edge-adapter connection at cobblr-edge:// and it routes through the tunnel. The standalone edge bridge or the OctoPrint-Cobblr plugin can be that agent. The tunnel carries stats, not video, so to glimpse a LAN camera remotely, an opt-in snapshot relay (off by default) pushes a frame every few seconds for a near-live thumbnail from your phone.

Connecting a machine

Adding a machine asks two things: what kind it is (Bambu Lab, Klipper, Prusa, RepRapFirmware (Duet), Marlin, and so on: really, how it talks) and how to connect (straight to the machine, or through a manager like OctoPrint or FDM Monster). The two are independent, so you can drive most printers either way.

• Built-in drivers: FDM Monster, the edge adapter, Bambu, Elegoo over its own SDCP protocol, and a mock driver for trying the flow with no hardware.
• The driver catalog has ready-made drivers you browse and install: OctoPrint, Klipper (Moonraker), Duet (RepRapFirmware), PrusaLink, FluidNC (GRBL lasers and CNC), and Home Assistant. Installing one is data, not a Cobblr update, and you can paste your own manifest for any other REST manager. Full current list: What Cobblr connects to. For a machine none of them cover, see Edge-bridge drivers.
• Connections carry a label, a base URL, and credentials (an API key, or a username and password), encrypted per workspace at rest. Edit one in place (rename, new host, rotate the key, pause) rather than deleting and recreating, because deleting one cancels and unlinks everything that depended on it.

Bambu, two halves. Sign in with your Bambu account once: Cobblr discovers every printer on it (no IP to find, no access code to copy) and follows their status. For control, add LAN access on the printer (its IP and access code): starting a print, pushing a file, the chamber camera, and the SD-card file list then route over your edge bridge on the printer's own network, while the cloud keeps filling in telemetry and history.

Starting a farm, or moving one in. Two header buttons stand up a fleet quickly:

• Add several takes a pasted list of printer URLs (one per line, as url, name, url, or name, url, apikey), makes one direct connection per printer, installs the drivers each needs, and can drop them all in a pool. Detect firmware probes each URL to guess OctoPrint vs Klipper vs PrusaLink vs Duet.
• Import farm reads an existing FDM Monster and brings its printers in either way: recreate each as its own direct connection of the matching type (dropping FDM Monster from the path), or keep FDM Monster and mirror its printers into a Cobblr pool.

Drivers, and Bambu credentials, in more depth

A driver is the adapter that speaks a manager's or firmware's API. The Elegoo SDCP driver is a recent, hardware-unverified first release, so if you run one, tell us what your printer does.

Your Bambu password is used once to get a token, which is stored encrypted and never reaches your browser.

The fleet floor

The page opens on a live floor: one card per machine across every connection, each with a status colour band (printing, idle, error, offline) and, when Cobblr has a job on it, the file and a progress bar.

• The count chips are filters (All, Working, Needs you, Idle, Off), and a header counts the fleet ("12 machines, 4 printing, 1 error"). A Compact view fits far more machines on screen.
• Needs you says why on the tile: clear the bed, print failed, or a printer error.
• Machines group by pool, so a pool of individual printers reads as one farm even across connections. Drag a tile and the others shift to show where it lands. The layout is remembered for the whole workspace, so the floor can mirror your actual shop.
• A Cameras view turns the floor into a webcam wall.
• Batch actions: select several machines to pause, resume, stop, or clear their beds, or drag a library file straight onto a tile to print it there.
• Fleet tiles and machines are the same machines. Link a printer to one of your machines: the tile wears the machine's name and photo, and the machine's page shows a live chip (printing 46%, needs clearing, idle, offline) beside its lifecycle state.

How the floor stays fast and honest

The floor paints instantly from the last-known state and refreshes in the background, and machines sort working-first. An unreachable manager flags its own row instead of blanking the rest, and at farm scale each manager's device list is briefly cached and time-boxed so one slow manager can't freeze the view. A machine collection's Fleet tab (3D Printers, Laser Cutters) scopes to that collection's devices, while Digital Fabrication stays the whole-shop floor.

The cockpit

Open a printer for its cockpit: a two-column dashboard with the camera, live nozzle and bed temperatures, and filament on one side, and controls and files on the other.

• The jog pad: X/Y as a cross with Home in the middle, a Z column, and a 1/10/100 mm step selector.
• Pause and Resume on a running print, where the manager supports them (Cobblr only asks the manager).
• The files panel lists what is on the machine's own storage next to your print history. Any print that ran as a Cobblr job has a one-click Print again, and a Bambu on LAN lists its SD-card files so you can start one with no re-upload.
• Open machine jumps to that printer's full record, and a machine's page has an Open controls button back to the cockpit.

How files get their names and pictures

A file that matches a past print borrows that print's model name and picture (a chip marks whether it is known from the SD card, the Cloud history, or both), and files the history can't name get their preview read from the gcode or 3MF the slicer wrote.

Sending a file and the print queue

1. Drop a 3MF or gcode file into the library once. Cobblr stores it and pulls out the slicer's own thumbnail and estimates (time, material, grams, parts-per-plate), so the library is a visual shelf.
2. Send any file as a new job, routing it by a linked machine, a specific printer, a pool, or a printer tag (a group like "PLA").
3. Confirm. Send is the one action that starts a real print, so it always asks first. A background worker then polls the job to completion.

• The queue updates live, pages through history, and filters by Active, Failed, or Done. Click any job for its full error, timeline, and the build or material it draws.
• Retry is one click, in place, on a failed or cancelled job, but a cancelled job stays cancelled.
• Awaiting assignment: a job that matched no printer (or several) waits with a Pick printer button instead of guessing.
• On a real fleet the pickers are type-to-search and the queue has checkboxes for batch send, cancel, and remove.

Routing safety

A tag resolves to a real printer inside Cobblr before the file goes out, and a job aimed at a printer that isn't on its connection is refused rather than sent to the wrong machine.

Pools and the cross-machine queue

A pool is a set of machines that can span different connections: how you run a pile of individual printers (one OctoPrint here, a Klipper there) as one farm with no manager in the middle. Queue jobs onto the pool and a worker drips each one onto the next machine to come free, so you can throw a batch at the farm and walk away. The worker only decides which machine gets each file, and it never streams gcode.

Production runs

A production run turns a pool into a batch job: pick a pool, a plate file, and a target quantity (with parts-per-plate if one plate makes several). Cobblr queues exactly the plates needed, drips them onto free printers, and replaces failures on its own. A plate only counts when you clear its bed with a good verdict, so a scrapped plate is reprinted without you thinking about it. The run closes itself at target and can be paused, resumed, or cancelled mid-flight from the floor.

When a print finishes

A finished print flags the machine needs clearing. When you clear the bed:

• Came out good closes the linked task.
• Scrapped puts the filament and machine usage back and leaves the task open.

Why the verdict exists, and what updates when

A printer reporting "completed" means the gcode finished, not that a good part is on the bed, so Cobblr never auto-starts the next pool job onto an occupied bed. It treats the follow-on effects by how costly they are to undo: your filament count and machine hours update the moment the print finishes, but the to-do that print was for waits for your verdict. A brief network blip while polling doesn't flip a healthy print to "failed", because it retries first.

Keeping inventory and machines in step

Because your machines sit next to your inventory, a print can keep both honest.

• Filament. On a printable file, Cobblr reads the material and grams straight from the slicer metadata and matches a spool by material, so you don't retype what the slicer already computed. On completion the grams deduct from that spool.
• Builds. Link a job to a build (a recipe of components with an output) and sending the job decrements each component from stock and increments the finished product, so an order becomes "queue the job, watch stock drop and the finished count rise." A scrapped or failed print returns the materials.
• Machine usage. Link a job to a machine and each completed print accrues a lifetime print count and hours on that machine, which you can pair with a maintenance threshold ("nozzle due at 500 prints").

Each of these runs through a wire on the completion event, so you can retune or disable it like any automation.

Watching for failures

While a print runs, Cobblr can score frames from the machine's camera into a rolling failure score. When it crosses your threshold it can pause the print automatically, flag the machine, and send a notification.

• You tune the sensitivity, the detector, whether it auto-pauses or only alerts, and how often it samples. The rolling score means one bad frame won't trip it.
• Local first: it prefers a local model on your bridge, so the frame never leaves your network and costs no AI tokens, and falls back to your workspace's vision AI when there is none.
• The verdict shows on the picture it judges: the camera wall and each fleet tile carry a graded badge (green, amber, red, and a "paused by AI" flag when it tripped), the cockpit overlays the same badge on the live frame, and a strip under it says when the AI last looked, through which detector, and how many samples this print.
• Check now takes a single live reading and tells you whether it would trip the auto-pause.

For webcams, streams, and what to buy, see Cameras.

Pluggable detectors: PrintGuard, Obico, your own

The detector is pluggable and, like machine drivers, an installable manifest: your AI provider's vision, PrintGuard, Obico's ML API, or any scorer you run on your network. Detectors come in two shapes: frame scorers take frames Cobblr samples from the camera. Services like PrintGuard can watch their own cameras instead: you link each machine to one of the detector's cameras from a dropdown. PrintGuard also offers a "send frames" mode for when the detector cannot reach the camera but Cobblr can (PrintGuard 2.3.0 or newer).

You can hand a printer to the detector straight from Cobblr, which registers it using the credentials Cobblr already holds (they stay server-side). Tell Cobblr the detector owns that printer and Cobblr stands down for it, so one printer of a shared Bambu connection can go to the detector while Cobblr keeps running the rest: Cobblr stops its own camera pull, won't send that printer jobs, and marks it "watched by detector" on the floor while its status keeps flowing. Coordinate-not-control holds: the model and the pause live where the hardware is, and Cobblr only asks.

Print updates and history

As a job runs, Cobblr can post updates (started, 25 / 50 / 75%, completed, failed) to Discord, in-app, or email.

• Set it up once at Me → Notification channels by adding digifab.print.* on the Discord channel with your server's webhook URL.
• In Discord each update is a colour-coded card with progress, time remaining, elapsed, and filament, the live webcam snapshot embedded in the post, and a link back to the feed, so one message replaces the two bots people usually run. The snapshot works wherever Cobblr can reach the camera.
• Print rules make the updates configurable: a scope (all printers, one printer, a tag) crossed with a channel, a cadence, and a message template, so your resin printer and your big machine can post on different cadences to different places.

The history view is a read-only rollup over every print Cobblr tracked: a summary (count, success rate, filament used, machine hours), a prints-per-day trend of completed against failed over the last 7, 30, or 90 days, and a per-printer breakdown with each machine's success rate so a problem printer stands out.

Sharing machines across workspaces

A workspace running an edge bridge can grant another Cobblr workspace scoped access to a checklist of its bridge machines via a single-use invite. The other workspace never receives the machine's credentials. Every call is proxied through your bridge, which enforces the grant's scope and expiry live. Sharing a machine grants a physical capability (the other workspace can actually start prints on your hardware), so treat minting a grant like handing over a key. Grants are listed and revocable at any time.