Docs
Pages

Printers

Bambu Lab (LAN mode)

Connects to Bambu Lab X1, X1 Carbon, P1P, P1S, A1, A1 mini and H2D printers over your local network: live status, AMS filament slots, uploads, start, pause, resume, cancel, camera and G-code lines. Bambu's cloud is not used.

For users

On the printer

  1. On the printer screen, open Settings, then WLAN. The H2 series and P2S call it Network. Connect the printer to your network if it is not connected yet.
  2. On the same screen, turn on LAN Only Mode. The access code (8 characters) appears next to it. It changes each time you switch the mode on, so read it after you switch it on.
  3. If the screen offers Developer Mode, turn it on too. Without it, newer firmware may accept status requests but refuse commands from third party software.
  4. Note the IP address shown with the network name.
  5. Find the serial number on the label at the back of the machine, or under Device in Bambu Studio.

While LAN Only Mode is on, the printer does not use Bambu's cloud, so the Bambu phone app and cloud printing stop working for it. Menu names differ between models and firmware versions.

In SlicerX

  1. Add a printer and choose Scan. Bambu Lab printers announce themselves on the network, and SlicerX only listens, so yours appears within a few seconds with its serial number filled in.
  2. If it does not appear, choose Bambu Lab and enter the IP address and serial number.
  3. Enter the access code. SlicerX stores it in your keychain and never shows it again.

Network and firewall

The computer needs to reach the printer on:

Port Protocol Used for
8883 TCP, MQTT over TLS status and commands
990 TCP, FTPS uploading files (data connections use high ports the printer chooses, commonly 50000 to 50100)
6000 TCP, TLS camera frames on A1 and P1
322 TCP, RTSPS X1 camera (not used yet)
2021 and 1990 UDP the printer's announcements, for scanning

Guest Wi-Fi networks and VLANs that isolate clients block all of these.

Common problems

Message or symptom Cause and fix
"rejected the credentials" The access code is wrong. It changes when you toggle LAN Only Mode; read it again from the printer.
"no status report after connecting; check the serial number" The serial number does not match the printer at that address.
"is unreachable" Wrong IP, printer asleep or off, different subnet or VLAN, or a firewall blocks 8883.
Upload fails or times out Port 990 or the passive data ports are blocked, or the SD card is missing or full.
A command is refused Developer Mode is off on firmware that requires it, or the printer is in a state that does not allow it (for example pausing while idle).
Camera returns nothing on an X1 X1 printers stream over RTSPS on port 322, which is not supported yet. A1 and P1 work.
Filament slots look wrong Slots read from the AMS as A1 to A4 for the first unit, B1 to B4 for the next. Third party spools without a tag report no remaining percent.

Untested on hardware

Checked against a simulator, not a printer. First things to check: H2D nozzle temperatures, whether Developer Mode is required on your firmware, and the estimated time left (community documentation disagrees on its unit; SlicerX reads minutes).

For integrators

Plugin id bambu-lan. Capabilities: status, events, upload, start, pause, resume, cancel, camera, filament slots, G-code console. Network: lan:8883, lan:990, lan:322, lan:1900, lan:2021. Tools: bambu-lan.status (read), .queue (queue), .start, .pause, .resume, .cancel, .gcode (start).

Printer config: host, serial, credentialRef (keychain entry with the access code), optional port (8883), ftpPort (990) and cameraPort (6000).

Protocol

  • MQTT 3.1.1 over TLS, user bblp, password is the access code. Subscribe to device/{serial}/report, publish to device/{serial}/request. TLS certificates are self-signed, so the connection encrypts but does not authenticate the printer; the access code is the credential.
  • On connect, one pushall requests the full state. Documentation says P1 printers should not receive it more than every five minutes; SlicerX sends it once per connection. Later push_status reports carry only what changed and are merged.
  • project_file starts a .gcode.3mf uploaded over FTPS (url ftp:///name, param Metadata/plate_N.gcode). The slotMap in start options becomes ams_mapping, an array of global tray ids (unit times four plus slot, 254 for the external spool, -1 for unused filaments). Plain .gcode starts with gcode_file.
  • Print options on start: bed_levelling, flow_cali, vibration_cali, layer_inspect and timelapse in project_file. Defaults follow what Bambu Studio sends (read from SelectMachine.cpp): bed leveling on, flow calibration off, vibration compensation off, first layer inspection on, timelapse off. Studio's Auto mode for leveling and flow calibration sends the boolean false plus a separate mode value whose wire key is not public, so SlicerX offers on and off only. Studio turns timelapse on when the printer can record one; SlicerX cannot tell, so it waits to be asked.
  • FTPS is implicit TLS on 990 with the same credentials. .bgcode files are refused.
  • Camera on port 6000: an 80 byte authentication packet, then 16 byte frame headers followed by JPEG data.
  • Discovery listens for SSDP NOTIFY broadcasts; it sends nothing.

Events and rate

Events are pushed. Status events are emitted when anything other than the timestamp changes. When the MQTT connection drops the printer reads as offline and reconnects every two seconds.

Testing

bambu_contract in tests/drivers.rs runs the contract suite against a fake broker, FTPS server and camera (the mock generates a throwaway certificate with openssl). Mock credentials: access code 12345678, serial 01S00C000000000.

Sources

Bambu Lab's LAN protocol is documented by the community: https://github.com/Doridian/OpenBambuAPI (mqtt.md, ftp.md, video.md).