Add GapLength option + fix Continuous-mode feed underrun - #8
Merged
Merged
Conversation
The 3mm gap sent by GAP/BLINE was hardcoded, but many small die-cut labels use a shorter physical gap (as low as ~1.5mm). A mismatch makes the firmware overshoot hunting for the next boundary, wasting 1-2 labels before it resyncs. GapLength (tenths of mm) is now a PPD/CUPS option, defaulting to 30 (3.0mm) to preserve existing behavior.
On Continuous stock there's no sensor to stop the feed at the real boundary, so the printer trusts SIZE's height as the whole feed pitch. Sending only the label's own height underfeeds by the physical gap, landing further into the next label on every subsequent print. GapLength is now added to SIZE's height when MediaTracking=Continuous (it still isn't sent as a GAP/BLINE command there, since Continuous means no sensing at all). Found while chasing a specific printer (2e3c:5757, a very short 12mm/2mm-gap label) whose gap sensor couldn't reliably track that pitch even after calibration, forcing a switch to Continuous mode - where this underfeed then showed up as consistently landing 2-3mm short of the next label. The underlying math bug is generic to any TSPL printer run in Continuous mode, but I'm not sure how common that setup is among this driver's users - flagging that uncertainty rather than assuming it's broadly needed.
…instead of padding Continuous
Whole-millimetre gaps go out as "GAP 3 mm,0 mm" again, so the default
stream is byte-identical to 1.3.4; fractions ("GAP 2.5 mm") are built
from integer tenths, which is in the TSC spec and locale-proof. A bare
1..9 or a value with a decimal point is read as millimetres, like
PrintSpeed's bare ips. Values under 1 mm on a sensor mode would go out
as GAP 0, which the firmware takes as "continuous" and remembers, so
they now warn and fall back to 3 mm; over 25.4 mm (the spec maximum)
clamps.
Continuous no longer pads SIZE: a continuous roll has no gap, and the
page height already is the feed length, so the +3 mm default would have
changed every existing Continuous queue after upgrade. The blind-feed
case (die-cut stock whose gap the sensor cannot hold) is now its own
MediaTracking choice, FixedPitch: GAP 0 plus SIZE = label + GapLength,
summed in tenths and rounded once so nothing accumulates label after
label.
PPD text now matches the code (first GAP argument, not second; used on
FixedPitch, not ignored), the INFO log shows the SIZE height, tracking
and gap actually sent, and the smoke test covers the guards, the bare
mm forms, PrinterDefault, and FixedPitch.
Contributor
|
@owlot thank you for your help! This is now added to new release. (baking now) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context / how I got here
I hit this while getting a specific printer working (QIN LabelPrinter / LW650XL PRO,
2e3c:5757— already merged in #6) with a very short label: 12mm tall, ~2mm physical gap. Its gap sensor couldn't reliably track that pitch even right after a successful power-on auto-calibration — it would print one label then fault red on the very next feed, regardless of whatGAPvalue the driver sent (tried the 3mm default and the measured 2mm, same result; even aPRINT 1,5single job with oneSIZE/GAPcommand only got through label 1). I don't have a second roll/printer to check whether that's a firmware limitation specific to this pitch or something else — I couldn't fully root-cause it, I just worked around it.I'm honestly not sure how broadly useful this is — most users are probably on Gap or BlackMark stock where this doesn't apply. Opening it so you can judge whether it's worth merging, not claiming it should be.
What's in this PR
GapLengthCUPS/PPD option (tenths of mm, default 30 = 3.0mm) — the gap/black-mark boundary length was previously hardcoded to 3mm inGAP/BLINE. Lets it be set per-queue for stock with a different physical gap.MediaTracking=Continuous(to sidestep the sensor issue above) surfaced a second, more generic bug: in Continuous mode there's no sensor to stop the feed at the real label boundary, so the printer just trustsSIZE's height as the whole feed pitch. Sending only the label's own height (no gap) underfeeds by the physical gap amount every time, landing progressively further into the next label.GapLengthis now added toSIZE's height specifically in Continuous mode (still not sent asGAP/BLINE, since Continuous means no sensing at all) to compensate.Fix #2 is a real logic bug independent of my specific printer — any TSPL printer run in Continuous mode would underfeed today. Fix #1 (configurable GapLength) is more narrowly about the sensor reliability issue I couldn't otherwise resolve.
Test plan
make testpasses (backend.sh, ids.sh, smoke.sh — added smoke cases for GapLength on Gap/BlackMark, and for the Continuous-mode SIZE-height compensation with both default and custom GapLength)cupstestppd ppd/tspl-label.ppd→ PASS (pre-existing size-name warnings only, unrelated)MediaTracking=Continuous GapLength=20printed two consecutive single-label jobs cleanly, feed stopping at the correct next-label position each time, no fault