Send prints to an Elegoo Centauri Carbon

Since v0.11.3 PrintStash can push a G-code file straight from its library to an Elegoo Centauri Carbon or Carbon 2 over your own network, then start, pause, resume, or cancel the print and watch temperatures and progress come back. Nothing goes through an Elegoo account or a cloud service.

Two things to know before you plan around it. The printer’s file list is not readable, so PrintStash can send files and start them but cannot show you what is already on the machine. And the upload path is beta with genuinely thin hardware evidence behind it: one partial community report on the original Carbon, and none at all on Carbon 2.

One provider, two different protocols

The Centauri Carbon and the Carbon 2 do not speak the same language, which is why the setup screen asks you which one you have.

The original Carbon uses SDCP v3 over a WebSocket on port 3030, with no authentication. PrintStash asks you to save the printer’s mainboard ID because the firmware’s own announcements get intermittent, and can stop entirely while the machine is idle, paused, or in an error state. With the ID stored, commands keep working through those states.

The Carbon 2 uses authenticated MQTT on port 1883. You need to enable LAN Only in the printer’s network settings and enter the access code the printer displays. That is the same shape as Bambu’s LAN mode, and the reasoning is the same: the local channel is the one that works without a vendor account.

Uploads take a third path on both models. The transfer is plain HTTP, chunked into 1 MiB multipart POSTs on the original Carbon and sent as a chunked PUT with Content-Range on Carbon 2, and it runs independently of the SDCP or MQTT channel carrying status and control. So a file can transfer while the control channel is quiet, and an upload failure and a control failure are separate problems with separate causes.

Setting one up

1. Give the printer a static address or a DHCP reservation. Everything below assumes the address will not move.
2. On a Carbon 2, enable LAN Only in the printer’s network settings and note the access code.
3. In PrintStash, add a printer and pick the Elegoo Centauri Carbon or Elegoo Centauri Carbon 2 preset. Enter the host address, plus the access code on Carbon 2.
4. On the original Carbon, save the mainboard ID in the printer’s settings once it has been detected. Skipping this is the usual reason commands work at first and then stop responding when the machine goes idle.
5. Open the printer’s Diagnostics tab. It reports the provider’s support level, capability checks, configuration checks, and live connectivity, and it returns no stored secrets, so it is safe to paste into a bug report. The same data is available at /api/v1/printers/<printer-id>/diagnostics.
6. Send a small G-code file from the library without auto-start, confirm it arrives, and start it from the printer for the first run.

What you get, and what is missing

Live status, temperatures, and progress come back on both models, along with pause, resume, cancel, starting a file already on printer storage, and uploading from the vault.

What is not there: the printer’s file inventory and remote deletion, raw G-code commands, print history import, and measured filament consumption. The inventory gap is a deliberate safety decision rather than unfinished work. The original Carbon’s file-list probe can terminate its printer daemon when it arrives with an empty payload, and Carbon 2’s documented file-list request does not answer on the firmware that has been validated, so PrintStash never sends either request.

Because measured consumption is Moonraker-only, per-print cost on a Centauri falls back to the slicer’s estimate. Elapsed duration does come back from the printer, though the compatibility matrix is careful to say that only Moonraker’s has been checked against real prints.

How beta this actually is

The provider is labelled beta, and what sits behind that label is thinner than the word usually implies.

The original Carbon’s upload path has one community report. It exercised pycentauri directly, then ran PrintStash 0.11.3 from source against the same physical printer: live status, model detection, and an upload-only send all completed, and an independent listing confirmed the file reached printer storage with the machine still idle. Start, pause, resume, cancel, and reconnect-while-paused were never exercised, because that printer had a filament runout fault and could not begin a job. The project files this as a partial smoke, not a completed validation.

Carbon 2’s upload path has no real-hardware report at all. The protocol logic is tested against mocked transports, which proves the code does what it intends and proves nothing about your firmware.

The practical reading: supervise the first few prints, keep an eye on the first upload of any firmware version, and send a report either way. The project’s hardware validation log is currently empty, and it is meant to be filled by people running the smoke tests rather than pre-filled by the maintainers.

What the library adds around it

Sending is the last step of a workflow that the printer itself has no opinion about. Each slice lives in PrintStash as a revision of its source model with the slicer settings parsed out of it, an outcome you can set, and one revision marked as the one to reprint. On a Centauri that record matters slightly more than usual, because you cannot browse the printer’s storage to see what you sent last time. One model, many G-codes covers how those outcomes work.

If your other machines are Neptune 4s, they connect through Moonraker instead and get the full capability set. Self-hosted print management for Elegoo owners covers running both families from one library.

Questions that come up

Does this need Elegoo’s cloud or an account?

No. Both paths are local: SDCP over a WebSocket for the original Carbon, authenticated MQTT for Carbon 2, and plain HTTP for the file transfer. PrintStash needs to reach the printer’s address on your network and nothing else. On Carbon 2 you have to enable LAN Only on the printer, which is the setting that makes the local channel available in the first place. If you want the same arrangement for other brands, printing over LAN without a cloud account covers what each provider requires.

Why can PrintStash send a file but not list the files on the printer?

Because probing for the list can break the printer. On the original Carbon, a file-list request with an empty payload can terminate the printer daemon, and on Carbon 2 the documented request does not answer on validated firmware. Rather than shipping a feature that sometimes takes the machine down, PrintStash never sends those requests and marks inventory and remote deletion as unsupported. The practical effect is that you manage what is on the printer from the printer, and manage what is in your library from PrintStash.

What is the mainboard ID for, and do I need it to upload?

It is for control reliability on the original Carbon, not for uploads. The firmware’s announcements become intermittent and can disappear while the printer is idle, paused, or in an error state, and the saved mainboard ID gives PrintStash a stable path to send commands through those states. HTTP upload does not use it at all, which is why an upload can succeed on a printer whose controls have gone quiet. Carbon 2 does not use a mainboard ID; it uses the access code instead.

Can I run a Centauri Carbon and a Neptune 4 in the same library?

Yes, and they connect through different providers. Neptune 4, Pro, Plus, and Max run Klipper, so they use the stable Moonraker provider through a guided preset rather than a second Elegoo implementation. That means the Neptune gets remote file inventory, print history import, and measured filament, and the Centauri does not. Both appear in the same printer list and both can receive files from the same library, but do not expect the same capability set from each.

Is upload safe to leave unattended?

Not yet, in my reading of the evidence. One partial report on the original Carbon and none on Carbon 2 is not enough to plan an unattended queue around, and the project’s own hardware validation log is empty. Upload itself is the least risky action, since it moves bytes and starts nothing, and starts remain explicit rather than automatic. Send files freely, supervise starts, and treat the first print after any firmware update as a new test.

Sources

• PrintStash provider support notes and the printers guide for the SDCP and MQTT connection details, the mainboard ID behavior, the chunked upload paths, and the reasons file inventory stays disabled. Read from docs/provider-support.md in the repository, which carries more detail than the landing docs.
• The v0.11.3 release notes for the upload feature itself, and the compatibility matrix for what each provider reports back in the shipped release. Checked August 19, 2026.