fix: batch printing corrupts the second label (feeds back, prints solid black) #1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When printing a run of multiple labels via the web UI (
/printwith count > 1), the first label prints correctly, but the second label pulls roughly 1/4 of the first label back into the printer and prints a solid block of black instead.The web UI currently paces labels with a fixed 2 s delay between jobs (
send_jobloop inwebui/p21_webui.py), because theESC ! ?status byte is silent on this unit so we can't poll for "ready". Hypotheses: (a) 2 s is shorter than the feed time for a 40 mm label, so the next job'sCLS/BITMAP/PRINTlands while the motor is still feeding the previous label; (b) the RFCOMM link needs re-syncing between jobs (the first-command-after-link-up drop behavior hints at a fragile command state machine).Fix direction: measure the actual feed time for a full label and use a generous delay (or make it scale with label length), and/or re-establish the link per label. Verify with a 3-label run and confirm each label is clean and fully separated.
Reported 2026-10-18 during web UI development (branch
webui).