Bambu Labs

Bambu Labs

Provenance: maintained in earthtojake/text-to-cad. Use the installed local skill files as the runtime source of truth; the repository link is only for provenance and release review.

Use this skill for local-network Bambu Lab print handoffs after a plain .gcode file already exists and has been validated. This skill does not slice models.

Safety Rules

• Default to dry-run plans. Real printer traffic requires --execute.
• Never start a print without --execute --confirm-start-print.
• Pause and cancel controls are live printer requests; default to dry-run plans.

Canceling a print requires --execute --confirm-cancel-print.

• Treat an explicit user request to print or start a specific job as live-start

authorization; do not pause for a second confirmation solely for physical checks. Still validate the G-code, inspect the dry-run payload, read printer status, prefer upload-only before upload-start, state the physical checks, and stop if validation/status/intent is unsafe or ambiguous.

• Do not ask for the printer serial by default; fetch it from the printer TLS certificate with serial or let send cache it.
• Prefer workspace-root bambu-printers.json over repeating access codes in commands. The file is local config and should be ignored by Git.
• Before a live start, state the physical checks: clear build plate, correct plate/filament/nozzle, safe surroundings, and operator nearby.
• Publishing MQTT is only a start request. Confirm acceptance with printer status/UI and physical observation.

CAD Viewer Handoff

After completing Bambu work that creates or modifies a local supported print artifact such as .gcode or .3mf, you must ALWAYS hand the explicit file path to $cad-viewer when that skill is installed. $cad-viewer must start CAD Viewer if it is not already running and return link(s) to the relevant created or updated file(s); if $cad-viewer is unavailable or startup fails, report that instead of silently omitting the handoff.

Workflow

1. Generate and validate plain G-code with $gcode. If no slicer is installed, install OrcaSlicer and retry; do not treat the missing slicer as a blocker. On macOS, prefer brew install --cask orcaslicer. 2. Configure the printer. The user can either give the IP/access code in the thread and let the agent write JSON, or edit bambu-printers.json directly. For a new printer setup or onboarding request, read references/new-printer-onboarding.md first. Walk the user through the model-specific touchscreen steps to find the IP and LAN access code, and make Enable LAN Only plus Enable Developer Mode explicit before running local start workflows.

python scripts/bambu_lan_print.py config set \
  --printer a1-mini \
  --host 192.168.1.34 \
  --access-code 12345678 \
  --model a1-mini \
  --fetch-serial

Manual JSON shape:

{
  "printers": {
    "a1-mini": {
      "host": "192.168.1.34",
      "access_code": "12345678",
      "model": "a1-mini"
    }
  }
}

On A1/A1 Mini, find the IP and LAN access code on the printer touchscreen under network/LAN settings. Enable LAN Only and Developer Mode when offered, then power-cycle before retrying local start commands.

3. Read status before live work:

python scripts/bambu_lan_print.py status \
  --printer a1-mini \
  --push-all \
  --wait-seconds 10

4. Dry-run the exact handoff, inspect the JSON payload, then run upload-only. Only after upload succeeds should you run upload-start. If the user explicitly asked to print or start the job, proceed to upload-start --execute --confirm-start-print after the validation, status, and upload checks pass. If the user only asked to prepare, slice, upload, or review, stop before the start request.

Handoff Modes

--handoff template-project is the validated A1 Mini path from this repo's LAN debugging. It starts from validated plain .gcode, copies a known-good same-printer .gcode.3mf template, replaces Metadata/plate_N.gcode, writes the plate MD5, uploads the project to the FTPS root, and publishes print.project_file with url: ftp:///<name>.gcode.3mf.

python scripts/bambu_lan_print.py send \
  --printer a1-mini \
  --gcode /tmp/job.gcode \
  --handoff template-project \
  --template-project /path/to/same-printer-template.gcode.3mf \
  --action upload-start

Execute after review when the user explicitly asked to print or start, or after physical confirmation when intent is unclear:

python scripts/bambu_lan_print.py send \
  --printer a1-mini \
  --gcode /tmp/job.gcode \
  --handoff template-project \
  --template-project /path/to/same-printer-template.gcode.3mf \
  --action upload-start \
  --execute \
  --confirm-start-print

--handoff plain uploads cache/<name>.gcode and publishes print.gcode_file. Keep it for diagnostics or printers/firmware where this is known to work. On the tested A1 Mini, direct plain G-code was uploaded successfully but gcode_file failed or was ignored, so do not use it as the A1 Mini live-start path.

--handoff bambox-project packages plain .gcode with bambox, uploads the .gcode.3mf project to FTPS root, and publishes print.project_file. Currently enabled only for p1s-0.4 with PLA, ASA, or PETG-CF. Known but disabled until validated profiles exist: a1-mini-0.4, a1-0.4, x1c-0.4, and p1p-0.4.

Common Debugging Commands

Fetch/cache serial:

python scripts/bambu_lan_print.py serial \
  --printer a1-mini \
  --json

Clear a stale printer error after fixing the underlying cause:

python scripts/bambu_lan_print.py clear-error \
  --printer a1-mini \
  --execute

Use --mqtt-qos 1 --wait-after-publish 10 on send when debugging whether the printer acknowledged the MQTT publish and what status it reported immediately afterward.

Print Controls

For a running print, use dedicated print-control commands rather than ad hoc MQTT snippets. These commands publish only a control request; they do not upload files or start a new job. Read status after execution to confirm the printer state changed.

Dry-run pause payload:

python scripts/bambu_lan_print.py pause \
  --printer a1-mini

Execute pause and collect printer reports:

python scripts/bambu_lan_print.py pause \
  --printer a1-mini \
  --execute \
  --mqtt-qos 1 \
  --wait-after-publish 10

Dry-run cancel payload. The Bambu LAN command sent to the printer is stop:

python scripts/bambu_lan_print.py cancel \
  --printer a1-mini

Execute cancel only when the user explicitly asks to cancel/stop the print or after confirmation when intent is ambiguous:

python scripts/bambu_lan_print.py cancel \
  --printer a1-mini \
  --execute \
  --confirm-cancel-print \
  --mqtt-qos 1 \
  --wait-after-publish 10

Failure Modes

• gcode_file returns result: fail or leaves the printer IDLE: plain G-code upload worked, but the firmware rejected or ignored direct local start. For A1 Mini, switch to template-project.
• Project uploaded under cache/ starts then fails with print_error: 83935248 or 0500-C010: clear the error, upload project handoffs to FTPS root, and use ftp:///<name>.gcode.3mf.
• file:///sdcard/cache/... or local HTTP URLs appear accepted but nothing starts: stop using those URL forms for this workflow.
• Bambu Studio or OrcaSlicer project export crashes on macOS: do not keep retrying GUI-backed project export. Use OrcaSlicer for plain .gcode, then this skill for handoff.
• Stale gcode_state: FAILED or HMS after enabling Developer Mode: clear the printer error and power-cycle before retrying.
• FTPS login works but upload fails with 553 or missing cache/: check printer storage/SD card status before MQTT start.
• MQTT status works but start does not: confirm serial, access code, Developer Mode/LAN Only status, and the exact handoff payload before retrying.

Read references/new-printer-onboarding.md for new printer setup, references/local-lan-protocol.md for protocol details, and references/real-printer-checklist.md before first live use on a new printer.

Bambu Lab Local LAN Protocol Notes

Use this reference only when planning or debugging against a real local printer. Bambu does not provide this skill with a stable public local-print API contract, so treat these as observed FTPS/MQTT behaviors.

Required Inputs

• Validated plain .gcode.
• Printer LAN IP/hostname.
• Printer access code.
• Printer serial for MQTT topic device/{serial}/request; fetch it from the

printer TLS certificate with serial or let send fetch/cache it.

• Handoff mode: template-project, plain, or bambox-project.

Workspace-root bambu-printers.json stores printer IDs, hostnames, access codes, models, and cached serials. It is local config and should be ignored by Git.

Transport

• FTPS upload: implicit TLS on port 990.
• MQTT control/status: TLS on port 8883.
• Username: bblp.
• Password: printer access code.
• TLS verification is off by default because local printers commonly use

device/self-signed certificates.

• The helper rejects public IPs/hostnames unless --allow-nonprivate-host is

set.

• FTPS data connections may require TLS session reuse. The helper reuses the

control TLS session for uploads and listings.

MQTT Topics

• Request topic: device/{serial}/request.
• Report topic: device/{serial}/report.
• status --push-all subscribes to reports, then publishes pushing.pushall

to request a full state report.

• Publishing a start payload is a request, not proof of accepted motion.

Handoff Payloads

Template Project

Validated on an A1 Mini during local LAN debugging:

1. Start from a validated plain .gcode. 2. Copy a known-good same-printer .gcode.3mf template. 3. Replace Metadata/plate_N.gcode and update Metadata/plate_N.gcode.md5. 4. Upload the resulting .gcode.3mf to FTPS root, not cache/. 5. Publish print.project_file with root FTP URL.

Representative payload:

{
  "print": {
    "command": "project_file",
    "param": "Metadata/plate_1.gcode",
    "project_id": "0",
    "profile_id": "0",
    "task_id": "0",
    "subtask_id": "0",
    "subtask_name": "job",
    "url": "ftp:///job.gcode.3mf",
    "md5": "PROJECT_MD5_UPPERCASE",
    "timelapse": false,
    "bed_type": "auto",
    "bed_levelling": true,
    "flow_cali": true,
    "vibration_cali": false,
    "layer_inspect": true,
    "use_ams": false,
    "ams_mapping": ""
  }
}

Plain G-code

The plain path uploads cache/<job>.gcode and publishes:

{
  "print": {
    "command": "gcode_file",
    "param": "cache/job.gcode"
  }
}

On the tested A1 Mini, byte-for-byte verified uploads still produced gcode_file failure/idle behavior. Use this path only for diagnostics or printer firmware where it has been validated.

Bambox Project

The optional bambox-project path packages plain G-code into .gcode.3mf for enabled profiles, validates the archive, uploads it to FTPS root, and publishes the same project_file shape as template projects. Current enabled profile is p1s-0.4; A1/A1 Mini are disabled until a validated bambox profile exists.

Observed Failure Modes

• Direct G-code rejected: MQTT report after gcode_file may include

{"command":"gcode_file","result":"fail","reason":"error string"}. Stop and use a project handoff.

• Direct G-code ignored: uploaded file exists, HMS is empty, target

temperatures stay at zero, and gcode_state remains IDLE. Do not keep cycling path variants.

• Project in `cache/` fails: project_file can be accepted and then fail

with print_error: 83935248 / 0500-C010. Clear the error and upload project files to FTPS root with ftp:///<name>.gcode.3mf.

• HTTP/file URLs inert: file:///sdcard/cache/... and local HTTP URLs may

be accepted without fetching or starting. Do not use them for this workflow.

• Bambu/Orca project export crash: GUI-backed CLI project export on macOS

can crash inside AppKit/BambuStudio. Use slicer CLI only for plain .gcode.

• Stale printer state: after LAN Only/Developer Mode changes, clear errors

and power-cycle. Status can retain stale FAILED/HMS values.

• Storage unavailable: if FTPS auth works but upload fails with 553, or

status reports no SD/storage, resolve storage before MQTT start.

Use clear-error --execute only after the underlying cause is fixed. It publishes print.clean_print_error and does not start motion.

New Printer Onboarding

Use this reference whenever the user asks to set up, add, pair, configure, or test a new Bambu Lab printer for local LAN handoff. The goal is a calm, step-by-step setup where the user always knows what is safe, what is private, and what the agent will do next.

Agent Flow

1. Start by confirming this is setup only. Say that no upload or print will happen during onboarding unless the user explicitly asks later. 2. Ask for the printer model or family if it is not already known. Use a stable local printer id such as a1-mini, a1, p1s, p1p, x1c, or h2d. 3. Tell the user you need two values from the printer touchscreen: printer IP address and LAN access code. Explain that the serial is fetched from the printer certificate and should not be requested by default. 4. Immediately give the model-specific touchscreen steps below. Do not just ask for the IP and access code without helping the user find them. 5. Make the LAN prerequisites very explicit: the user must Enable LAN Only and Enable Developer Mode before live local start commands. If either option exists and is off, stop setup and ask them to enable it first. 6. After the user provides the IP and access code, store them with config set in workspace-root bambu-printers.json, using --fetch-serial. Do not repeat the access code in the final response. 7. Run status --push-all --wait-seconds 10 and summarize the result in plain language: reachable or not, idle/running/error, SD/storage present, and any print_error or HMS entries. 8. If setup succeeds, offer the next safe step as a dry-run handoff plan. Do not upload or start anything during onboarding unless the user explicitly asks.

What To Say First

Use a short, reassuring prompt like this:

I can set this up safely. I need the printer's LAN IP address and LAN access
code from the touchscreen. Before you send them, please enable LAN Only and
Developer Mode; local starts often fail or become read-only if Developer Mode is
off. I will store the code only in the workspace-local ignored config and fetch the
serial from the printer automatically.

Then give the matching steps for their printer family.

Touchscreen Steps By Printer Family

A1 / A1 Mini

1. On the printer touchscreen, open Settings. 2. Open Network or WLAN. 3. Connect the printer to the same trusted local network as this computer. 4. Enable LAN Only. 5. Enable Developer Mode in the same network/LAN area when shown. 6. Record the IPv4 address shown on the network screen. 7. Record the LAN access code shown near the LAN Only or Developer Mode controls. If it is all zeros, refresh/regenerate it or toggle LAN Only off and on, then record the new code. 8. Power-cycle the printer after changing LAN Only or Developer Mode.

P1P / P1S

1. On the printer screen, open Settings. 2. Open Network or WLAN. 3. Confirm the printer is on the same trusted local network as this computer. 4. Enable LAN Only. 5. Enable Developer Mode. If it is not visible, update firmware or stop before live local start workflows. 6. Record the printer IPv4 address. 7. Record the LAN access code. If the code is all zeros or blank, refresh it or toggle LAN Only off and on, then record the new code. 8. Power-cycle the printer before the first local status check.

X1 / X1C / X1E

1. On the printer touchscreen, open Settings. 2. Open Network or WLAN. 3. Confirm the printer is connected to the same trusted local network. 4. Enable LAN Only. 5. Enable Developer Mode. If it is not visible, update firmware or stop before live local start workflows. 6. Record the IPv4 address. 7. Record the LAN access code from the LAN/network screen. 8. Power-cycle the printer after changing LAN settings.

H2D / Newer Bambu Printers

1. Open Settings on the printer touchscreen. 2. Open Network, WLAN, or the printer's LAN settings panel. 3. Confirm local network connectivity. 4. Enable LAN Only. 5. Enable Developer Mode. 6. Record the IPv4 address and LAN access code. 7. Power-cycle after changing LAN settings.

For an unknown Bambu model, guide the user to the printer's network/WLAN settings, then require the same four items before continuing: same local network, Enable LAN Only, Enable Developer Mode, and collect IP plus LAN access code.

Agent Commands

Use the active Python environment:

python scripts/bambu_lan_print.py config set \
  --printer a1-mini \
  --host 192.168.1.34 \
  --access-code 12345678 \
  --model a1-mini \
  --fetch-serial

Then check status:

python scripts/bambu_lan_print.py status \
  --printer a1-mini \
  --push-all \
  --wait-seconds 10

Use the model-specific printer id in both commands. If sandboxing blocks local network access, rerun the same command with permission to contact the printer.

Smooth Failure Handling

• If the printer is unreachable, ask the user to confirm the IP, same Wi-Fi or

VLAN reachability, and that the printer is awake.

• If MQTT status fails but TLS serial fetch worked, first confirm **Developer

Mode** is enabled, then power-cycle and retry status.

• If the access code is rejected or all zeros, ask the user to refresh the LAN

access code on the printer and rerun config set --fetch-serial.

• If status returns stale FAILED, print_error, or HMS entries after enabling

LAN Only or Developer Mode, stop. Ask the user to resolve the physical issue, power-cycle, then retry status. Use clear-error --execute only after the underlying cause is fixed.

• If setup succeeds, do not imply that live printing is validated. Say that LAN

connectivity is configured and status works; live printing still requires the real-printer checklist, a dry-run plan, upload-only, and supervised start.

Real Printer Checklist

Use this before any --execute run against a physical Bambu Lab printer.

Credentials And Network

• Confirm the printer IP/hostname is on the trusted local network.
• Confirm LAN Only/Developer Mode is enabled when the printer exposes it,

especially on A1/A1 Mini.

• Store the access code in workspace-root bambu-printers.json with config set; do not

print it in final messages.

• Fetch/cache serial with serial or config set --fetch-serial.
• Run status --push-all and verify the intended printer responds.
• If LAN settings changed after failed starts, clear stale errors and

power-cycle before retrying.

Job

• Confirm $gcode generated and validated the plain .gcode.
• Confirm scale, orientation, supports, material profile, nozzle, and bed type.
• For A1 Mini LAN start, prefer --handoff template-project with a known-good

same-printer .gcode.3mf template.

• Use --handoff plain only for diagnostics or firmware where gcode_file is

already validated.

• Use --handoff bambox-project only when the exact printer/nozzle profile is

enabled by the script.

• For project handoffs, upload to FTPS root and use ftp:///<name>.gcode.3mf.

Physical Printer

If the current user request explicitly asks to print or start the job, treat that request as live-start authorization for this checklist. State these physical checks before the live command and proceed if automated validation and printer status are healthy. Ask for another confirmation only when the request intent is ambiguous or a validation/status check raises concern.

• Build plate is installed, clear, clean, and appropriate for the material.
• No failed-print remnants, loose tools, tape scraps, or debris are in the

printer.

• Filament is loaded and appropriate for the sliced file.
• Operator is nearby for heat-up, homing, and first-layer observation.
• Camera or direct observation is available.

First Live Sequence

1. Run the exact send command without --execute and inspect the plan. 2. Run send --action upload --execute first. 3. Check status/UI/storage if possible. 4. Re-run the dry send --action upload-start plan. 5. Run send --action upload-start --execute --confirm-start-print when the user explicitly asked to print/start, or after confirmation when intent is unclear. 6. Poll status and watch the printer until the first layer is clearly normal.

If status reports print_error or HMS after a failed attempt, stop. Resolve the cause, optionally run clear-error --execute, then poll status before retrying.