"Any printer" is the ambition. This page is the truth.
Marketing gets one line on the front page; this table gets the rest. If a printer is not on it, TigerSpool does not support it. If it is on it at 🧪, that means someone has to do work before it does.
Status of this page: everything marked 🟢 proven below was proven with this repository's firmware, on real printers. Nothing here is claimed on the basis of documentation alone.
| Level | What it means for you | |
|---|---|---|
| ✅ | Automatic | Add the printer once in Tiger Studio. TigerSpool finds it, connects, and works. Nothing to configure on the device. |
| ⚙️ | One setup step | Works, but the printer needs one thing switched on or read off its own screen — usually LAN mode, sometimes an access code. Once. |
| 🧪 | Experimental | Not finished. May be partly implemented, may be unimplemented, may be broken by a printer firmware update. Do not buy hardware for this. |
| Brand | Models | Level | Transport | Prototype status | What's needed |
|---|---|---|---|---|---|
| Creality | K2, K2 Plus | ⚙️ | WebSocket :9999 |
🟢 proven on hardware | Nothing: the printer accepts local requests while it stays on Creality Cloud. |
| FlashForge | Creator 5 / 5 Pro, AD5X | ⚙️ | HTTP :8898 |
🟢 proven on hardware | Serial number and check code, both from the printer's network info screen. Imported automatically if the printer is in your TigerTag account. |
| Bambu Lab | A1, A1 mini, A2L | ⚙️ | MQTT/TLS :8883 |
🟢 proven on hardware | LAN mode on, plus the serial and the 8-character access code from the printer screen. Imported automatically from your account. |
| Snapmaker | Artisan, J1, J1s, U1 | ⚙️ | Moonraker WebSocket :7125 |
🟢 proven on hardware | Nothing — Moonraker needs no authentication on the LAN. The printer's IP is all it takes. |
| Bambu Lab (cloud) | X1, P1, and any printer not on your LAN | 🧪 | MQTT/TLS to Bambu's broker, one session shared by every cloud printer on the account | 🟢 reading proven on hardware (A1, X1C) · writing not supported | Read only: slots are shown, a tag cannot be written - Bambu's cloud does not take the command. Depends on a Bambu session token that Tiger Studio obtains and stores in your account; the device never signs in to Bambu itself. The token expires roughly every three months and has to be renewed in Studio. |
| Elegoo | Centauri 2, Centauri 2 Combo, Centauri Carbon 2, Centauri Carbon 2 Combo | ⚙️ | MQTT :1883 (plain TCP) |
🟢 reading proven on hardware (Centauri Carbon 2 Combo, with and without its CANVAS - every Centauri runs the same firmware) · writing not yet confirmed on a printer | Serial number and the MQTT password (an "Access Code" on the printer). Imported automatically from your account. |
| Anycubic | Kobra 3 / 3 Max (V2), Kobra X, ACE units - or the single external spool of a printer without one (extfilbox) |
⚙️ | MQTT/TLS :9883 |
🟢 reading proven on hardware (Kobra X) · writing not yet confirmed on a printer | LAN mode, and the printer must be paired in AnycubicSlicerNext at least once — its broker credentials exist nowhere else. Tiger Studio reads them from there into your account. |
| Anycubic (cloud) | any Anycubic not in LAN mode | ⚙️ | MQTT/TLS to Anycubic's cloud broker :8883, one session shared by every cloud Anycubic on the account |
🟢 reading and writing proven on hardware (Kobra X) | Add the printer to Tiger Studio in cloud mode: it writes the account's token and Anycubic's shared client certificate on the printer's document, and the device reads both from there. The device signs in as web, so it stays connected beside Tiger Studio and the slicer. When a new slicer sign-in revokes the token, refresh the printer in Tiger Studio. |
How many at once depends on which: a Bambu or an Anycubic takes far more of the device's memory than the others, so the limit is a load budget rather than a count - see CONNECTION-BUDGET.md.
Anycubic TLS — the supposed blocker does not exist. Tiger Studio's protocol notes say the broker must be pinned to TLS 1.2 because it requests an optional client certificate that a TLS 1.3 stack aborts on. Probed directly against a Kobra X (modelId 20030) in LAN mode, that is not what happens: the broker completes both TLS 1.3 (
TLS_AES_256_GCM_SHA384) and TLS 1.2 (ECDHE-RSA-AES256-GCM-SHA384), sends no certificate request at all, and accepts every mbedTLS-friendly suite tried — includingECDHE-RSA-AES128-GCM-SHA256, the ESP32's default. Its certificate is self-signed, as expected.This may vary by model or firmware, so it is recorded as an observation rather than a rule. But on this hardware the ESP32 will handshake, and the largest stated risk for the Anycubic backend is not present. The device's own mbedTLS has since completed it too.
Legend for implementation status: 🟢 implemented in this firmware and verified against a physical printer · 🟡 implemented, not fully verified · 🔵 protocol fully documented and proven on real hardware elsewhere (Tiger Studio), but no firmware backend written yet · 🔴 nothing at all.
Both have a firmware backend, over the LAN, and both read slots on real printers. Unlike every other protocol in this project, neither had to be reverse-engineered: both were already documented and working in Tiger Studio, from live captures of the vendors' own slicers against real printers:
renderer/printers/elegoo/PROTOCOL.mdrenderer/printers/anycubic/PROTOCOL.md
That turned support from open-ended research into a porting job.
Both protocols were re-checked live on 2026-09-08, against a Centauri Carbon 2 at 192.168.40.102 and a Kobra X at 192.168.20.200, using exactly the topics and payloads the firmware backends send:
| Elegoo | Anycubic | |
|---|---|---|
| Connect | CONNACK rc=0 with user elegoo + access code |
CONNACK rc=0 over TLS 1.2, self-signed |
| Register | {"error":"ok"} |
n/a |
| Read | 2005 → Canvas connected:1, four trays with brand, type, #RRGGBB |
getInfo → state:success code:200, box -1 with four slots |
| Shape | matches the backend's parser | matches the backend's parser |
So the transports, the credentials, the topics and the payload shapes are all
correct. The device then read both printers itself (1.36.0): the Centauri
Carbon 2's four trays and the Kobra X's four slots, the same the printers report
to Tiger Studio. The credentials the device seemed to lack - the Elegoo access
code, the Anycubic username and acuModelId - were in the account all along;
the import was discarding them.
mbedTLS on the ESP32 completes the Anycubic handshake - TLS 1.2, self-signed, no client certificate. That was the biggest open question in the protocol notes.
Not yet confirmed on a printer: writing a slot, on either brand. The commands are the ones Tiger Studio sends (below), but a write has not been read back from the printer after the device sent it.
| Elegoo | Anycubic | |
|---|---|---|
| Transport | MQTT over plain TCP, port 1883 | MQTT over TLS, port 9883, self-signed |
| Auth | broker username elegoo + password, plus the serial number |
deviceId + username + password |
| Read slots | method 2005 (with Canvas) / 1061 (single extruder) |
getInfo on the multiColorBox topic |
| Write a slot | method 2003 (Canvas) / 1055 (single extruder) |
setInfo on the same topic |
| Colour | #RRGGBB, uppercase |
[r, g, b] array |
| Materials | a captured 50-entry filament_code table keyed by type × name |
~30 accepted names, sent verbatim |
| Discovery | UDP broadcast, port 52700 | GET http://<ip>:18910/info, no auth |
Elegoo is in some ways simpler than Bambu Lab — no TLS at all.
Anycubic's TLS. Tiger Studio's notes say the broker demands TLS 1.2 and requests an optional client certificate that a TLS 1.3 stack aborts on. The Kobra X did neither (see the note under the matrix), and the ESP32 handshakes with it. Another model or firmware may still behave as the notes say.
Anycubic credentials cannot be obtained from the printer. The /info
endpoint does not expose them and they cannot be derived from what it does expose
— that was established exhaustively, not assumed. They exist only in
AnycubicSlicerNext's own config file, which Tiger Studio decodes on the desktop
and writes to your TigerTag account.
For TigerSpool that is not an obstacle, it is the product working as designed: the desktop does the part that is impossible on a 2.0" screen, and the device imports the result. But it means an Anycubic printer must have been paired in AnycubicSlicerNext at least once, and the documentation has to say so plainly rather than letting a user discover it as a failure.
An Anycubic printer is reachable either over the LAN or through Anycubic's cloud, and the account says which. The LAN backend exists now. A cloud-mode printer keeps no open local ports at all: there is nothing on the network to connect to, and the only route is Anycubic's own service — signed REST requests against a second broker, with signing secrets that live inside the closed slicer and app binaries.
That is not a variant of the LAN backend with a flag set. It is a second client against a different service, and the device cannot obtain its own credentials for it any more than it can for the LAN one. The realistic shape is the Bambu cloud pattern already in this firmware: Tiger Studio holds the session and the account carries a token the device presents. Nothing in the firmware can be built until that is decided, because it determines what the account has to store.
Bambu Lab's cloud path is that pattern, and it is built: Tiger Studio holds the session, the account carries the token, and the device reads slots with it.
- Other models. The captures come from specific printers. A protocol that holds across a brand's range is worth far more than one that fits one machine.
- Testing on other models, and a confirmed slot write on each brand.
A slot name is what the user reads on the box and matches against the machine in front of them. It has to be the name the printer's own interface uses, and the same one Tiger Studio shows — a slot called something else here is a slot the user has to translate in their head.
These are taken from Tiger Studio's renderers, which are the reference:
| Brand | External | Units |
|---|---|---|
| Bambu Lab | Ext. |
A1–A4 for the first AMS, B1–B4 for the second, and so on. An AMS HT is one heated slot and is labelled HT1, HT2… — the printer reports those units as id 128 and up, not as a fifth AMS |
| Creality | Ext. |
1A–1D for the first CFS box, 2A–2D for the second |
| FlashForge | Ext. |
1A–1D for the material station. T1–T4 are something else: the Creator 5 Pro's tool-changer nozzles, not station slots. |
| Elegoo | Ext. |
S1–S4 on a Combo - the CANVAS unit and its four colours. A Centauri without CANVAS has Ext. only. |
| Snapmaker | — | E1–E4, one per extruder |
| Anycubic | see below | A1–A4, B1–B4, … one row per ACE unit |
There is one external slot per printer. Not one per CFS, AMS or ACE unit —
one for the machine. It belongs to the printer, and it is drawn once. That is why
Tiger Studio puts Ext. on the first row and an invisible spacer in the same
column on every row after it: the grid stays aligned without inventing an
external spool that does not exist.
Both backends here follow it: the external slot is index 0, written once, before any unit.
The letter and the digit swap places between brands. Bambu is
unit-then-position (A1), Creality is box-then-position (1A). They are not
typos.
Reported slots are not loadable colours. A Kobra X has four inputs in its head. One feeds a splitter serving four ACE units — sixteen colours — and the other three take one spool each, so the machine holds nineteen colours. Four ACE units are sixteen slots, not twenty.
The protocol does not describe the wiring, and a backend must not try to. You receive the list of ACE units. You do not learn which head input each one hangs off, and you do not need to: the printer resolves a box and slot to a physical path itself. Modelling the topology would be inventing a fact the machine never sends.
What the hardware does, from the bench:
- A Kobra X has four inputs on the print head. Each takes one spool directly, or an ACE unit. So the same machine can be four direct colours, or sixteen through four ACE units, or a mix — and the report looks the same shape either way.
- A Kobra S1 and S1 Max have a slot the machine calls "Holder". That
is the
Ext.equivalent, one per printer, consistent with the rule above.
What is not settled is how box -1 should be labelled. Tiger Studio's
renderer builds a per-slot prefix of E for box -1, giving E1–E4 — four
external slots, against the one-per-printer rule. The header comment in that same
file says [Ext.] [A1] [A2] … instead. The two disagree inside one file, and the
Kobra X reports four slots on box -1 while the S1's "Holder" is plainly one.
Decide it against a machine, not against the report. Everything else in this table is settled.
Slot names are decoupled from slot indices: renaming is safe, adding a slot changes the protocol mapping and is not.
It means: TigerSpool can write a material name, a colour and nozzle/bed temperatures into a numbered slot, and can read back what is currently in each slot to show it on screen.
It does not mean:
- Loading or unloading filament. TigerSpool sets metadata. It does not drive the extruder. No supported printer exposes load/unload the way it exposes slot configuration.
- Any colour you like. FlashForge accepts only its own 24-colour palette; a tag's colour is snapped to the nearest one. Bambu Lab accepts exact RGB.
- Any material name you like. Each printer has a fixed vocabulary. Materials the printer does not know are mapped to the closest one it does.
What that looks like in practice. A verified end-to-end assignment on a FlashForge AD5X: the tag said PLA High Speed, R3D,
#DC123F; the printer ended up showing PLA,#F82D29. The colour was snapped to the palette's nearest entry and the "High Speed" variant was dropped, because those are the only values the printer accepts. Nothing failed — but the device must say the colour was adapted, or a user will read a correct result as a bug.
- Working during a print. Changing slot configuration mid-print is not supported and may be refused by the printer.
Printer firmware updates. Every protocol here except Snapmaker's is reverse-engineered from a vendor's private API. Vendors change them without notice and owe nobody compatibility. A printer that worked last month can stop.
LAN mode. FlashForge and Bambu Lab gate their local APIs behind a mode that is off by default (on a Bambu Lab, Developer mode as well). This is the single most common reason a correctly configured printer shows as offline. On a FlashForge Creator 5 or 5 Pro with FlashForge's standard firmware, LAN mode also turns FlashForge Cloud off; the official FlashForge × TigerSystem firmware keeps both on.
Network segmentation. Guest networks, VLANs and client isolation on the access point will all prevent TigerSpool from reaching a printer that is otherwise perfectly configured. They must be on the same network segment.
Silent acknowledgements. At least one printer answers "success" to commands it did not understand. Where the protocol allows it, TigerSpool re-reads slot state after writing to confirm the change actually landed — but confirmation is not possible on every protocol.
The architecture is built so that a new brand is one class implementing one interface, and touches nothing else. What that class has to provide:
- Connect and stay connected over whatever transport the printer speaks, recovering on its own when the network drops.
- Report slots — how many, what they are called, and what is currently in each one.
- Accept an assignment — translate a decoded TigerTag into the printer's own material vocabulary and colour constraints, and send it.
- Tell the truth about failure — including detecting the case where the printer claims success and does nothing.
See CONTRIBUTING.md.