Skip to content

Start typing to search the documentation.

to navigateto open

Printers

Monitoring & Managing Printers

Check printer status, resolve errors, and manage printers day-to-day.

Once your printers are connected, the Printers page (under Operations) is where you’ll keep an eye on them day-to-day.

The printer list

The printer list can be viewed two ways:

  • Table view: a sortable, searchable table showing each printer’s name, model, site, status, and when it was last seen. Good for managing larger fleets.
  • Card / camera view: a grid of cards with live camera snapshots (for printers that support a camera), useful as a “wall display” to see what’s printing at a glance.

Printer status

StatusWhat it means
OfflineThe agent can’t reach the printer right now.
IdleReady and waiting for a job.
ReadyManually marked ready after maintenance.
DispatchingA job is being sent to the printer.
PrintingA job is actively printing, with progress and time remaining.
PausedThe current job is paused.
DoneThe current job finished and is awaiting outcome confirmation.

Printers also report how a job ended: completed or failed, which feeds job history and reprint suggestions.

The printer detail page

Selecting a printer opens its detail page, which includes:

  • Current job: name, progress, time remaining, who submitted it, and its approval status.
  • Loaded materials: a table of what’s in each slot, with a link to update it.
  • Camera snapshot: the most recent image from the printer’s camera (if it has one), refreshed automatically, with a link to view a timeline of past snapshots.
  • Notes: a free-text field for your team to leave notes about this printer (for example, “reserved for client work”).
  • Active errors: any issues reported by the printer or detected by Pluraprint.
  • Maintenance history: every period this printer has been out of service, with the reason and who took it down. See Marking a Printer Down.
  • Printer info: model, when it was added, and when it was last seen.

What each printer can do

Not every printer supports every action. A Bambu Lab machine can pause, resume, and stop a running print; a Formlabs printer hands its job to PreFormServer, which then owns it, so those controls don’t apply. Pluraprint knows what each model supports and only offers the actions that will actually work, rather than showing a button that fails when you press it.

CapabilityWhat it enablesExample
Pause / ResumePause and resume a running print from Pluraprint.Bambu Lab
StopAbort a running print remotely.Bambu Lab
CameraPeriodic snapshots and a snapshot timeline.Bambu Lab, Formlabs Form 4 series, Debug
Material reportingThe printer reports what’s loaded, keeping slots in sync automatically.Bambu Lab (AMS), Formlabs (resin)
Error reportingThe printer reports its own faults, shown on the printer page.Bambu Lab, Formlabs

Everyday actions

ActionWhen you’ll use it
Pause / ResumeTemporarily halt a print (to check on it, or to swap something) then carry on. Available on printers that support it.
Stop PrintEnd a print that’s going wrong (wrong material, a failing part, a safety concern). This can’t be undone: the part is scrapped and the job has to be run again from the start. Available on printers that support it, and requires the Stop permission.
Mark ReadyAfter clearing a jam or finishing maintenance, to tell Pluraprint the printer can take new jobs again.
Confirm OutcomeAfter a job finishes, confirm whether it succeeded or failed. This affects job history and reprint suggestions.
Mark DownTake a printer out of service for maintenance, with a reason everyone can see. Choose whether it goes down now or after its current job. See Marking a Printer Down.
Return to ServicePut a printer that’s down back to work, optionally noting what you fixed.
Dismiss ErrorsClear an error (individually or all at once) once you’ve resolved the underlying issue.
EditUpdate the printer’s name, site, enabled status, or connection details. Enabling and disabling a printer lives here, under the Enabled checkbox. It takes the machine in or out of the fleet entirely, and a disabled printer is hidden from everyone who can’t edit printers. For maintenance, use Mark Down instead, so the machine stays visible with its reason.
DeletePermanently remove a printer and its history. This can’t be undone.

Errors

Errors shown on a printer’s detail page come from two sources:

  • System errors: detected by Pluraprint (for example, the agent lost its connection to the printer).
  • Printer errors: reported by the printer itself (for example, a filament runout or temperature fault). These update automatically as Pluraprint polls the printer: a fault appears when the printer starts reporting it and clears on its own once the printer no longer does.

Every error is shown the same way regardless of who made the printer. Each one carries:

  • a severity: critical, error, warning, or info, so you can tell a thermal fault from an advisory message at a glance;
  • a category: material, temperature, motion, connectivity, safety, and so on, which is what makes it possible to see “three printers with material problems” across a mixed fleet;
  • the manufacturer’s own code where there is one (a Bambu Lab HMS code, for instance), shown separately as Printer code so it is not confused with the error description. You can use it to look the fault up in the vendor’s documentation or quote it to their support.

Resolve the underlying issue on the printer. Printer-reported errors clear automatically on the next status check; you can also dismiss any error (individually or all at once) to tidy your team’s view. When a printer is marked down, its list card shows only Down instead of repeating its errors; open the printer detail page to review them.

When a job doesn’t finish sending

Sending a job to a printer means transferring the file to it and waiting for the machine to confirm it has begun. On a slow network, or with a large file, that can take several minutes.

If Pluraprint loses contact partway through, it can’t tell whether the print started or not, so it deliberately does nothing rather than guess. The job stays in Dispatching and the printer shows Lost contact while sending a job. Pluraprint then watches the printer, and within a status check or two one of two things happens:

  • The print did start. The job moves to Printing on its own, with its material usage, history, and notifications all recorded as normal. Nothing for you to do.
  • The print didn’t start. The job returns to the queue and can be sent again.

This is why a job in that state is not sent to another printer in the meantime: doing so is how the same model ends up printed twice, once on each machine. If a job sits in Dispatching for much longer than a few minutes, check that the printer is powered on and that its site’s agent is connected: Pluraprint needs to hear from the printer to settle it.

Prints started outside Pluraprint

A printer in your fleet can still be used directly: someone loads a file from a USB stick at the machine’s own screen, or sends a job from the manufacturer’s app. Pluraprint calls that an unmanaged print: a print it did not start and knows nothing about.

By default nothing happens to it. Pluraprint simply can’t queue anything to that printer until the machine is free again, because it isn’t.

Administrators who need the fleet to be exclusively Pluraprint’s can turn on Stop prints not started by Pluraprint under General settings. While it is on, Pluraprint stops unmanaged prints automatically. It is deliberately cautious about it: stopping a print scraps the part and wastes the material, so it only acts when it is certain. In particular, it never stops a print when:

  • the printer’s model can’t be stopped remotely (a Formlabs machine, for example). You’ll see an error asking you to stop it at the machine instead;
  • Pluraprint can’t positively tell who started the print. Identification comes from the file name the machine reports, so a print it can’t read is left alone rather than guessed at;
  • Pluraprint believes one of its own jobs is on that printer, or is in the middle of sending one: a disagreement about our print is never resolved by aborting it;
  • the printer is marked down. A machine that is deliberately out of service is outside the policy, so maintenance and test prints are safe.

An unmanaged print also has to still be there several status checks later before anything is stopped, which keeps a printer that was simply slow to report its job from being interrupted.

Either way, an unmanaged print appears in the printer’s Active errors as Print not started by Pluraprint, with the machine’s own name for the print where it reported one, and clears by itself once the machine is free. Every stop Pluraprint issues on its own initiative is written to the audit log against the printer.

Camera snapshots

For printers with a camera (Bambu Lab models and the Debug printer), Pluraprint periodically captures snapshots: useful for checking on a print remotely or reviewing what happened after a failed job. Viewing snapshots requires the appropriate permission; ask an administrator if you don’t see this option.

Some printers need their camera stream enabled on the machine itself before Pluraprint can capture anything: for Bambu Lab H2S and H2D, see Bambu Lab Printers.