fit() cut words the moment a line overran, so the style row printed as "Electro, Synth-…" -- the one line a customer scans for -- while the extension's own label engine printed it whole. Step the font down to ~70% of its authored size first (still legible at 203 dpi) and only ellipsise if it still will not fit. Returns (text, font) so callers draw with whatever size actually fitted. Verified on the rfid65 render: the full "Electro, Synth-pop" at a slightly smaller bold. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| mac | ||
| .gitignore | ||
| ASSESSMENT.md | ||
| build.cmd | ||
| chafcheck.cs | ||
| daemon.cs | ||
| GTSPL_SDK_C.dll | ||
| GTSPL_SDK.dll | ||
| hidapi.dll | ||
| PROGRESS.md | ||
| README.md | ||
| start-daemon.cmd | ||
| UHFPrimeReader.dll | ||
| zlib.net.dll | ||
pricegod-urovo-daemon
The Windows counterpart to the Mac rfid-daemon. Instead of a Chafon gun writing a
loose chip while a Dymo prints a separate sticker, this drives the Urovo D812R+ (RFID)
to print the label AND encode the UHF chip in one pass on the composite (paper+chip) rolls.
It listens on http://localhost:7790/ with CORS *, so it's a drop-in for the PriceGod
extension's existing daemon.js client — same port, same JSON shape.
Run it
Double-click start-daemon.cmd (leave the window open while you work). That's it —
no Node, no .NET SDK, no gitea clone. It's a self-contained .exe.
To rebuild after editing daemon.cs: double-click build.cmd.
What's inside
daemon.cs— the service (C#, .NET Framework 4.x).pricegod-urovo-daemon.exe— the compiled daemon.GTSPL_SDK.dll,GTSPL_SDK_C.dll,zlib.net.dll— the Gainscha/Urovo print SDK (must sit beside the .exe). Copied from the vendor Windows SDK.
The print/encode sequence is a straight port of the proven gtcheck.cs rfidgo path:
SET RIBBON OFF → continuous geometry (GAP 0, RFID rolls blind the optical gap sensor)
→ writeUHF → draw text + QR → printlabel → read-back verify.
Routes
| method | path | body | returns |
|---|---|---|---|
| GET | /status |
— | {ok, ready, status, statusText, printer} |
| POST | /print-encode |
{sku, releaseId, artist?, title?, price?, condition?, w?, h?, gap?} |
{ok, sku, releaseId, epc, verified, status} |
| POST | /write-tag |
alias of /print-encode (the daemon.js name) |
same |
| GET | /read-tag |
— | {ok, epc, sku, releaseId, recognized} |
| POST | /calibrate |
— | RFID auto-calibration |
| POST | /recover |
— | ribbon-off + one feed to clear a fault |
Quick test (PowerShell):
Invoke-RestMethod http://localhost:7790/status
SKU ↔ EPC scheme (⚠ verify)
The 96-bit EPC (12 bytes) is packed as: 6 bytes 14-digit timestamp SKU · 4 bytes
release_id · 2 bytes 0xEC01 marker. This lives in the Epc class in daemon.cs and
is the only thing that needs to change if it must match a different (Mac/Chafon) layout —
nothing else depends on the byte order. Confirm by reading an existing tag: put a
Chafon-written record at the antenna and GET /read-tag.
DYMO LabelWriter 450 on macOS — the PPD you will need again
Not the daemon, but it lives here because mac/dymo.py drives the same printer.
macOS auto-adds a USB LabelWriter 450 with the generic CUPS driver
(*PCFileName: "dymo.ppd", *ModelName: "DYMO Label Printer"). That PPD ships 10 fixed
label sizes and no CustomPageSize/VariablePaperSize block — so a custom paper size
made in the macOS page-setup dialog can never reach the printer. CUPS silently falls back
to w81h252 (Address, 28.6 × 88.9 mm), and a 54×24 mm label design comes out rotated 90°
and shrunk, with a big blank area. Nothing is wrong with the extension's labels.js.
mac/dymo-24x55.ppd is the generic PPD patched to add the shop's 24×55 mm price stock, in
both feed orientations, so the right one can be picked in the print dialog:
| PageSize | pt | mm | roll |
|---|---|---|---|
pg55x25 |
72 × 155 | 25.4 × 54.7 | ~25 mm wide, label runs 55 mm along the feed |
pg55x25L |
155 × 72 | 54.7 × 25.4 | ~55 mm wide, label runs 25 mm along the feed |
John's price roll is the landscape-feed kind → use pg55x25L.
sudo lpadmin -p <queue> -P mac/dymo-24x55.ppd # apply (queue on JING5: make_it_soso)
sudo lpadmin -p <queue> -m drv:///sample.drv/dymo.ppd # revert to stock
Re-apply after any macOS update or after re-adding the printer — both revert the queue to the generic driver and the symptom comes straight back.
Regenerate from the pristine driver PPD — once applied, the queue's own PPD is already
patched and patch_ppd.py will refuse it:
ppdc -d /tmp/ppdout /usr/share/cups/drv/sample.drv
python3 mac/patch_ppd.py mac/dymo-24x55.ppd /tmp/ppdout/dymo.ppd # byte-identical, PASSes cupstestppd
Two traps it handles: margins are set to 2 pt sides / 4 pt ends instead of the driver's
stock 14.9 pt, which would eat 10.5 mm of a 55 mm label; and every one of the 31 languages
in *cupsLanguages needs a translation string per new choice or cupstestppd FAILs.
Dead end for next time: LabelPrinter-*.pkg in ~/Documents is not the DYMO driver —
it's the generic bundle for the PM-246S/Wagtail printers.
Notes / open items
- Default label geometry is
65×37 mm, continuous (GAP 0). Adjust to your actual RFID roll via thew/h/gapfields, or change theDEF_*constants. - The label layout (text lines + QR) is functional, not yet pixel-matched to the 51×19
Dymo design in the extension's
labels.js. - The Chafon gun is still needed for reading a loose tag off a shelf — the Urovo can only read/write a tag physically inside the printer.