Supporting PT-P910BT / Cube XP #60
Comments
|
neat! i really appreciate that they seem to keep a consistent protocol (and publish the spec).
ahh fun. without a deep look into the spec i'd probably try to differentiate by DPI (assuming new models may also be 360), and use a marker trait / type constraints on the methods that need it. then you can hang other methods off those definitions, eg. trait Dpi {
/// Buffer line type
type Line;
// Any the other constant-ish's that vary by DPI
..
// Any methods you need that're consistent for any DPI
..
}
pub struct Dpi180;
impl Dpi for Dpi180 {
type Line = u16;
..
}one thing to consider is that in the end we do need to be able to hold a printer object regardless of DPI so it probably is better to avoid a generic on the
i think these are related... the printer should automatically feed and cut the label once it's finished receiving the buffer. in the past i have seen this when the configuration (maybe buffer length calculation?) was not quite correct so the device was still waiting for more data / didn't realise it was done. |
This is about as minimal an implementation as I can manage at the moment, though it still passes around the resolution more than I might like. Tested on both a PT-P910BT and a PT-P710BT. Closes ryankurte#60. (Also adds debug logging of data read from the USB device alongside logging of data written.)
The raster command reference for the 900 series (https://download.brother.com/welcome/docp100407/cv_ptp900_eng_raster_102.pdf) looks remarkably similar to that for the 700 series, but the PT-P910BT doubles the resolution of the PT-P710BT (360 DPI versus 180 DPI).
From some very rudimentary editing of the existing code (adding the relevant device entry, increasing the tape pixel size and margins, and increasing the 16 byte line size to 70 as documented in the 900-series PDF), I'm able to get a PT-P910BT to print at least some intelligible content (a QR code and text, although the printer doesn't send a printing completed status - even though we've explicitly enabled status notifications, so
rust-ptouchdoesn't realize the print has finished and times out rather than ejecting the label).This is a promising start, but because a bunch of constants would have to change for the PT-P910BT to be supported, I wanted to file an issue and see if you had suggestions or preferences on how best to handle such an addition. (I am relatively experienced with programming in general, but am an extreme novice in Rust, so I am unlikely to have particularly idiomatic suggestions.)
(Regarding status notifications,
rust-ptouchdoes send the [1b 69 21 00] command to enable automatic status notifications, but all I see is a single status notification saying that the printer is printing, not that it has finished. I'm not sure if that means the printer is expecting more content before it finishes somehow, or if it somehow doesn't queue status notifications, or what happened. I don't have a Windows/Mac machine particularly handy to test out with the official software, but I might be able to do so if appropriate.)The text was updated successfully, but these errors were encountered: