octoturgeandClaude Opus 5
4d644937af
Print control (pause/resume/stop) and print start are now both confirmed
against the P1P on the LAN, and doing that turned up three real defects.
`start_uploaded_file` published fire-and-forget, so the printer's reply was
thrown away. Asking it to print a file it does not have returned `Ok(())`,
and watching `print.push_status` could not tell that apart from a successful
start, since both leave the machine IDLE for a while. The printer does in
fact answer - `{"command":"gcode_file","param":"...","reason":"error
string","result":"fail"}` - and it echoes the `sequence_id` we send, so
`request` correlates it. Both this and `control_print` now go out as
correlated requests and run the reply through `print_command_outcome`.
The upload and the print command disagreed about where files live. `upload`
cwd'd into `cache/` while the printable projects are in the card's root: the
root holds 43 `<name>.gcode.3mf` archives, `cache/` holds the printer's own
extracted `<project>_plate_N.gcode` working copies with `.gcode.bbl`
sidecars. Those extracted copies are not independently printable -
`gcode_file` with `param: "/cache/Cube_plate_1.gcode"` was rejected for a
file the FTPS listing shows is right there - while `project_file` with
`url: "ftp:///Cube.gcode.3mf"` started a print. So the destination is now a
parameter and both halves point at `SD_ROOT`.
What the hardware settled, recorded in the doc comments: the `ftp:///` url
spelling is right, `param: "Metadata/plate_1.gcode"` works for a
single-plate project, `use_ams: false` + `ams_mapping: ""` is accepted, and
a stop during PREPARE/RUNNING moves the printer to FAILED, which is how
Bambu reports an operator cancellation. What it did not settle: all three
control verbs answer `result: "success"` on an *idle* printer, so the reply
means "accepted", not "the state changed" - callers still have to read
`gcode_state` back.
`PrinterCommand::ControlPrint` makes this reachable from the cloud at all;
until now pause/resume/stop existed in the proxy with no way to send them.
Still no start-print variant, now for a different reason: the path around it
is missing, not the hardware proof.
Also: `list_dir` for any directory (how the layout above was found, without
sending a print command to guess), `request_raw` for probing an unconfirmed
command shape, and two examples - `bambu_cache_list` (read-only) and
`bambu_print_probe` (gated steps, `start` needing both IDLE and
--yes-start-a-real-print).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
76 lines
3.0 KiB
Rust
76 lines
3.0 KiB
Rust
use super::{GenericPrinter, PrinterBase, PrinterError};
|
|
|
|
pub struct KlipperPrinter {
|
|
base: PrinterBase,
|
|
}
|
|
|
|
impl KlipperPrinter {
|
|
pub fn new(id: &str, name: &str, host: &str) -> Self {
|
|
Self {
|
|
base: PrinterBase { id: id.into(), name: name.into(), host: host.into() },
|
|
}
|
|
}
|
|
}
|
|
|
|
impl GenericPrinter for KlipperPrinter {
|
|
/// OVERRIDE: real version is `POST /printer/print/pause`, `/resume` or
|
|
/// `/cancel` on Moonraker - note Klipper calls it "cancel" where Bambu
|
|
/// calls it "stop".
|
|
async fn control_print(&mut self, action: super::PrintControl) -> Result<(), PrinterError> {
|
|
let endpoint = match action {
|
|
super::PrintControl::Pause => "pause",
|
|
super::PrintControl::Resume => "resume",
|
|
super::PrintControl::Stop => "cancel",
|
|
};
|
|
println!("[{}] POST /printer/print/{endpoint}", self.base.name);
|
|
Ok(())
|
|
}
|
|
|
|
|
|
fn base(&self) -> &PrinterBase {
|
|
&self.base
|
|
}
|
|
|
|
/// OVERRIDE: a third, again-different body - Moonraker's real feed is a
|
|
/// WebSocket (see `adapters::moonraker`). This also shows the `Err`
|
|
/// path: an empty `host` fails immediately, same as any other vendor
|
|
/// would if it couldn't reach its printer.
|
|
async fn connect(&mut self) -> Result<(), PrinterError> {
|
|
if self.base.host.is_empty() {
|
|
return Err(PrinterError(format!("{} has no host configured", self.base.name)));
|
|
}
|
|
println!("[{}] connecting over WebSocket (Moonraker)", self.base.name);
|
|
Ok(())
|
|
}
|
|
|
|
async fn publish(&mut self, _payload: String) -> Result<(), PrinterError> {
|
|
// TODO: add publishing via HTTP
|
|
Ok(())
|
|
}
|
|
|
|
/// OVERRIDE: Moonraker's own **hypothetical** native API, not gcode injection - no
|
|
/// percent-to-PWM conversion needed since it already takes a
|
|
/// percentage directly. Real version:
|
|
/// `POST /printer/gcode/script?script=SET_FAN_SPEED SPEED=0.NN`.
|
|
async fn set_fan_speed(&mut self, percent: u8) -> Result<(), PrinterError> {
|
|
println!("[{}] Moonraker: SET_FAN_SPEED SPEED={:.2}", self.base.name, percent as f32 / 100.0);
|
|
Ok(())
|
|
}
|
|
|
|
/// OVERRIDE: real version is a multipart `POST /server/files/upload`
|
|
/// with `data` as the file part - Moonraker stores it on the printer's
|
|
/// virtual SD card, same upload-then-start model as Bambu/PrusaLink.
|
|
async fn upload_project_file(&mut self, file_name: String, data: Vec<u8>) -> Result<(), PrinterError> {
|
|
println!("[{}] POST /server/files/upload {file_name} ({} bytes)", self.base.name, data.len());
|
|
Ok(())
|
|
}
|
|
|
|
/// OVERRIDE: Moonraker's gcode-script endpoint, one line per call - same
|
|
/// idea as `set_fan_speed`'s `SET_FAN_SPEED` call above, just with an
|
|
/// arbitrary line instead of a hardcoded one.
|
|
async fn send_gcode_line(&mut self, gcode_line: String) -> Result<(), PrinterError> {
|
|
println!("[{}] POST /printer/gcode/script?script={gcode_line}", self.base.name);
|
|
Ok(())
|
|
}
|
|
}
|