first commit
This commit is contained in:
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2026 earthtojake
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -0,0 +1,209 @@
|
||||
---
|
||||
name: bambu-labs
|
||||
description: Dry-run, upload, and cautiously initiate local Bambu Lab print jobs from validated plain `.gcode`, using Bambu LAN FTPS/MQTT handoffs.
|
||||
---
|
||||
|
||||
# Bambu Labs
|
||||
|
||||
Provenance: maintained in [earthtojake/text-to-cad](https://github.com/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.
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```json
|
||||
{
|
||||
"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:
|
||||
|
||||
```bash
|
||||
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`.
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
python scripts/bambu_lan_print.py serial \
|
||||
--printer a1-mini \
|
||||
--json
|
||||
```
|
||||
|
||||
Clear a stale printer error after fixing the underlying cause:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
python scripts/bambu_lan_print.py pause \
|
||||
--printer a1-mini
|
||||
```
|
||||
|
||||
Execute pause and collect printer reports:
|
||||
|
||||
```bash
|
||||
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`:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Bambu Labs"
|
||||
short_description: "Dry-run and start local Bambu G-code handoffs"
|
||||
default_prompt: "Use $bambu-labs to dry-run a validated plain G-code handoff before starting it."
|
||||
@@ -0,0 +1,123 @@
|
||||
# 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:
|
||||
|
||||
```json
|
||||
{
|
||||
"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:
|
||||
|
||||
```json
|
||||
{
|
||||
"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.
|
||||
@@ -0,0 +1,139 @@
|
||||
# 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:
|
||||
|
||||
```text
|
||||
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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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.
|
||||
@@ -0,0 +1,56 @@
|
||||
# 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.
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user