Slow job printing on a Dymo LaberlWriter 450 Turbo (not turbo anymore)

[labiloute]

Hi,

Following the issue #5521 , we still experience trouble with the Dymo LabelWriter 450 Turbo linked to our Debian 10 buster with cups :

When I start a print on a LabelWriter 450 Turbo, it takes about 6-7 seconds until the print starts. The printing itself is then very slow. At the end of printing, the printer pauses for about 1-2 seconds and then advances the last piece of the label.

On Debian 10, with package driver or official driver, same result.
Tried various changes on the quirks file, unidir, no-reattach, with no success.

Does anybody have solved this one ? Any idea ?
Cheers

[tvanerven]

I have the exact same problem as this. I'll provide the debug information which I've managed to scrap up so far.

Our setup:

• Raspbian Buster (latest, downloaded a few days ago)
• A Python3 package for factory usage we're maintaining which talks to cups
• A couple of other python packages responsible for formatting stickers (never gave trouble but you never know)
• Installed printer using lpadmin on command line. Printer type used is a Dymo LabelWriter 450 Turbo, ppd file used is lw450t.ppd.

My tests:

• I have a local setup of the software running. The result is the same as described - roughly 8-9 seconds in, the first part of the label prints. It then pauses for roughly 10 seconds, before printing the last half-inch of the label.
• I have a Python test script set up which skips our software. The result is the same. I can attach a copy of this if desired.
• I used lp -d <printer> hello.txt to print; same result.

This suggests that the problem isn't in our software or it's alterations, but in cups.

My debug:

• I checked the cups error log. This shows a (very) long list of errors as such:

W [14/Oct/2020:15:42:20 +0200] [Job 10] CLabelWriterDriver::ProcessRasterLine(): page width is greater max page width, truncated

Not sure if this is relevant but I'm assuming ~3500 errors being thrown isn't desirable. It's likely this is being caused by our software or my test script, as this does not occur when using lp command to print.

• After finding a bunch of old threads, I found the quirks file located in /usr/share/cups/usb/. I added the no-reattach option as debug and rebooted the printer, reinstalling for good measure. No change.
• Right now, I'm trying to confirm whether the problem occurs on a similar setup, but on a LabelWriter 450 (not the Turbo). Will update post with results.

[tvanerven]

Tested with a 450 LabelWriter - the problem doesn't occur here in any test scenario I've outlined above.

[cmsedore]

I can offer/confirm that the problem does not occur on the LabelWriter 450 Twin Turbo (the one that holds two rolls of labels).

I have not found a solution for the 450 Turbo -- I've reverted to only using 'regular' LabelWriter 450s.

[schinds]

Try commenting out the "fix" line in usr/share/cups/usb/org.cups.usb-quirks (or wherever the quirks file is located on your system) and stop/start cups.service. I found that this "fix" actually created the problem on my system.
Perhaps it was based on an older version of the printer?

[schinds]

Dymo 450 Turbo (Issue #5521)

#This fix was put in to fix a printing delay problem and tells CUPS that the Dymo 450 Turbo does not support
#bidirectional comm. However, it does and this actually creates a delay problem. Commented out and printer works as it should.
#0x0922 0x0021 unidir

[michaelrsweet]

OK, so the issue is that the stock CUPS Dymo label printer driver won't have this issue, but the Dymo-supplied driver does because it assumes it has bidirectional comm with the printer (which is itself a driver bug).

We can remove the USB quirk over in OpenPrinting CUPS.

[michaelrsweet]

[master 628812b8e] Don't make Dymo unidirectional (Apple #5843)