Skip to main content
Version: Next (nightly)

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 and tracks the job to completion, across one printer or a farm of them.

The loop:

  1. Connect a machine: what kind it is, and how Cobblr reaches it.
  2. Drop a 3MF or gcode file into the library.
  3. Send it as a new job to a printer, a pool, or a tag, and confirm.
  4. When it finishes, clear the bed with Came out good or Scrapped.

Coordinate, not control​

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

  • A machine with its own API (Duet, Klipper): Cobblr talks to it directly, nothing sits in between.
  • A machine with no API (a Marlin printer) needs something in front to give it 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 in between, 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.
Reaching a printer behind your router from an instance elsewhere

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 independent things, so most printers can be driven either way:

  1. What kind it is (Bambu Lab, Klipper, Prusa, RepRapFirmware (Duet), Marlin, and so on), which is really how it talks.
  2. How to connect: straight to the machine, or through a manager like OctoPrint or FDM Monster.
  • A driver is the adapter that speaks a manager's or firmware's API. 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. The driver catalog adds installable drivers for OctoPrint, Klipper (Moonraker), Duet (RepRapFirmware), PrusaLink, FluidNC (GRBL lasers and CNC), and Home Assistant. Full list: What Cobblr connects to. For a machine none cover, see Edge-bridge drivers.
  • Bambu, two halves. Sign in with your Bambu account once and Cobblr discovers every printer on it. Then add LAN access on the printer (its IP and access code) to start prints, push files, use the chamber camera, and list SD-card files.
  • Add several takes a pasted list of printer URLs (one per line, as url, name, url, or name, url, apikey). Detect firmware probes each URL to guess OctoPrint vs Klipper vs PrusaLink vs Duet.
  • Import farm reads an existing FDM Monster: recreate each printer 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.
Drivers, Bambu, and fleet setup in more depth

Installing a driver is data, not a Cobblr update, and you can paste your own manifest for any other REST manager. The Elegoo SDCP driver is a recent, hardware-unverified first release. If you run one, tell us what your printer does.

Bambu discovery needs no IP to find or access code to copy, and follows each printer's status. Because Bambu gates third-party control, those LAN-access actions 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.

Add several makes one direct connection per printer, installs the drivers each needs, and can drop them all in a pool.

The fleet floor​

The page opens on a live floor.

  • One card per machine across every connection, with a status colour band (printing, idle, error, offline) and, when Cobblr has a job on it, the file and a progress bar.
  • A header counts the fleet ("12 machines, 4 printing, 1 error"). The count chips are also filters (All, Working, Needs you, Idle, Off). Compact fits far more machines on screen.
  • Needs you tiles say why (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 to rearrange. The layout is remembered for the whole workspace.
  • Cameras turns the floor into a webcam wall.
  • Batch: select several machines to pause, resume, stop, or clear their beds in one go, or drag a library file straight onto a tile to print it there.
  • 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.
How the floor stays fast at farm scale

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 each manager's device list is briefly cached and time-boxed so one slow manager can't freeze the view. When you drag a tile the others shift to show where it lands, so the floor can mirror your actual shop. 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.

  • One side: the camera, live nozzle and bed temperatures, and filament.
  • The other: controls and files. The jog pad is 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.
  • The files panel lists 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 the printer's full record. From a machine's page, Open controls opens this same 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. For pause and resume, Cobblr only asks the manager. It never drives the hardware.

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, routed 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 sits behind an explicit confirm. 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. 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 safeguards

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: a pile of individual printers (one OctoPrint here, a Klipper there) run 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.

  1. Pick a pool, a plate file, and a target quantity (with parts-per-plate if one plate makes several).
  2. Cobblr queues exactly the plates needed, drips them onto free printers, and replaces failures on its own.
  3. Clear each bed with a good verdict. A plate only counts then, 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 and never auto-starts the next pool job onto an occupied bed. 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 is yours

A printer reporting "completed" means the gcode finished, not that a good part is on the 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. 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 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.

  • A rolling failure score: Cobblr scores frames from the machine's camera and folds them into a rolling score, so one bad frame won't trip it. When it crosses your threshold Cobblr 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.
  • 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 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), and the cockpit overlays the same badge on the live frame.
  • Check now takes a single live reading and tells you whether it would trip the auto-pause.
  • Detectors are installable manifests, like machine drivers: your AI provider's vision, PrintGuard, Obico's ML API, or any scorer you run on your network.

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

Detector shapes, and handing a printer over to a detector

A strip under the cockpit badge says when the AI last looked, through which detector, and how many samples this print.

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, and Cobblr only asks.

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

  1. Go to Me → Notification channels.
  2. Add digifab.print.* on the Discord channel with your server's webhook URL.
  • 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.
  • History 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.
What a Discord update carries

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.

Sharing machines across workspaces​

  • Mint a single-use invite from a workspace running an edge bridge to grant another Cobblr workspace scoped access to a checklist of its bridge machines.
  • 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.
  • Treat a grant like handing over a key. It grants a physical capability: the other workspace can actually start prints on your hardware.
  • Grants are listed and revocable at any time.