likang/cad-Integration
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

first commit

Browse Source
This commit is contained in:
李康
2026-07-22 13:48:46 +08:00
commit c87751c3dc
2820 changed files with 726976 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
text-to-cad-main/plugins/cad/skills/bambu-labs/references/local-lan-protocol.md
+123
View File
@@ -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.
text-to-cad-main/plugins/cad/skills/bambu-labs/references/new-printer-onboarding.md
+139
View File
@@ -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.
text-to-cad-main/plugins/cad/skills/bambu-labs/references/real-printer-checklist.md
+56
View File
@@ -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.