Skip to main content

Digital fabrication

:::caution Experimental module

Digital Fabrication ships as Experimental. Everything on this page is real and in daily use, but the module is not yet promised to be stable, so its behaviour and shape can still change between releases. Inside Cobblr it wears an amber Experimental badge. An instance started with COBBLR_DISABLE_EXPERIMENTAL_MODULES=true skips experimental modules entirely, so on such an instance Digital Fabrication will not be there 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.

Coordinate, not control​

Cobblr hands a machine a file and follows the job. It doesn't drive the hardware move by move; the machine's own controller does that. Cobblr coordinates.

Many machines expose an API Cobblr can talk to directly, like Duet and Klipper, so nothing sits in between. A machine with no API of its own, like a Marlin printer, needs something in front to give it one. OctoPrint is the usual choice, and Cobblr talks to that. Bambu printers are their own case: 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): Cobblr can't reach them directly, so you 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.

An instance running somewhere other than 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; either 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 there is an opt-in snapshot relay (off by default) that 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, which is 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.

A driver is the adapter that speaks a manager's or firmware's API. A handful ship built in (FDM Monster, the edge adapter, Bambu, Elegoo over its own SDCP protocol, and a mock driver for trying the flow with no hardware). Beyond those, Cobblr carries a driver catalog you browse and install: ready-made drivers for 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. The full current list is in What Cobblr connects to; to reach a machine none of them cover, see Edge-bridge drivers. The Elegoo SDCP driver is a recent, hardware-unverified first release; if you run one, tell us what your printer does.

Bambu, two halves. Sign in with your Bambu account once and Cobblr discovers every printer on it, with no IP to find or access code to copy, and follows their status. Because Bambu gates third-party control, add LAN access on the printer (its IP and access code) and starting a print, pushing a file, the chamber camera, and the SD-card file list all route over your edge bridge on the printer's own network, while the cloud keeps filling in telemetry and history. Your password is used once to get a token, which is stored encrypted and never reaches your browser.

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 for you. Import farm reads an existing FDM Monster and brings its printers in either way you choose: 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.

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 to rename it, move it to a new host, rotate its key, or pause it, rather than deleting and recreating. Deleting a connection cancels and unlinks everything that depended on it.

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 floor paints instantly from the last-known state and refreshes in the background, machines sort working-first, and a header counts the fleet ("12 machines, 4 printing, 1 error"). The count chips are also filters (All, Working, Needs you, Idle, Off), and a Compact view fits far more machines on screen. A machine flagged Needs you says why on the tile (clear the bed, print failed, or a printer error). 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.

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. Select several machines to pause, resume, stop, or clear their beds in one batch, or drag a library file straight onto a tile to print it there.

Machines and fleet tiles are the same machines. Link a printer to one of your machines and the tile wears the machine's name and photo, while the machine's own page shows a live chip (printing 46%, needs clearing, idle, offline) beside its lifecycle state. 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 motion controls are a directional jog pad (X/Y as a cross with Home in the middle, a Z column, and a 1/10/100 mm step selector). A running print has Pause and Resume where the manager supports them, and Cobblr only asks the manager, it never drives the hardware.

The files panel lists what is on the machine's own storage next to your print history. 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. 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. An Open machine link jumps to that printer's full record, and from a machine's page an Open controls button opens this same cockpit.

Sending a file and the print queue​

Drop a 3MF or gcode file into the library once and 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. Then 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"). 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.

Send is the one action that starts a real print, so it sits behind an explicit confirm. After that a background worker 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. A failed or cancelled job has a one-click Retry in place, a cancelled job stays cancelled, and a job that matched no printer (or several) waits in awaiting assignment 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.

Pools and the cross-machine queue​

A pool is a set of machines that can span different connections, which is how you run a pile of individual printers (one OctoPrint here, a Klipper there) as one farm without a manager in the middle. Queue jobs onto the pool and a worker drips each one onto the next free machine as printers come idle, so you can throw a batch at the farm and walk away. The worker only decides which machine gets each file; 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), and 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 printer reporting "completed" means the gcode finished, not that a good part is on the bed. So a finished print flags the machine needs clearing and never auto-starts the next pool job onto an occupied bed. Cobblr 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. When you clear the bed you tap Came out good (which closes the linked task) or Scrapped (which puts the filament and machine usage back and leaves the task open). A brief network blip while polling no longer flips a healthy print to "failed"; it retries first.

Keeping inventory and machines in step​

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

  • Filament. Pick a printable file and 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​

A print can be watched while it runs. Cobblr scores frames from the machine's camera, folds them into a rolling failure score so one bad frame won't trip it, and when the score crosses your threshold it can pause the print automatically, flags the machine, and sends a notification. You tune the sensitivity, the detector, whether it auto-pauses or only alerts, and how often it samples. 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 no local model.

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. A one-tap Check now takes a single live reading and tells you whether it would trip the auto-pause.

The detector is pluggable, and like machine drivers it is 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, so 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, which needs 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, per printer, so one printer of a shared Bambu connection can go to the detector while Cobblr keeps running the rest: it stops its own camera pull, won't send that printer jobs, and marks it "watched by detector" on the floor, while the printer's status keeps flowing. Coordinate-not-control still holds: the model and the pause both live where the hardware is; Cobblr only asks.

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

As a job runs, Cobblr can post updates (started, 25 / 50 / 75%, completed, failed) to Discord, in-app, or email. In Discord each 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. Set it up once at Me → Notification channels by adding digifab.print.* on the Discord channel with your server's webhook URL; the snapshot works wherever Cobblr can reach the camera. The updates are configurable print rules: 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, through 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.