Calibration for LabelManager 280, 6mm tape

[jgoerzen]

Hello,

Thanks again for Labelle! It is working well on this device with the 12mm tape, but with 6mm tape, the text prints too far down and cuts off the bottom edge.

I am not entirely sure how to run the calibration on this tape, but I ran labelle --sample-pattern 64 and it gave this output:

[maresb]

Oh, this looks really odd. Usually the bottom edge is row 1.

Could you please try:

labelle --sample-pattern 32
labelle --sample-pattern 34

[maresb]

Is this the full height of the printable area?

[jgoerzen]

Hi,

Thanks for looking into this!

I should have mentioned: the widest tape the 280 can handle is a 12mm tape, and that tape works fine. It is only the 6mm tape that is giving trouble. The 6mm tape works from the Windows app.

Here's a photo with a bunch of samples:

From top to bottom, they are:

• 12mm tape with h=64 (works fine)
• 6mm tape with h=64 (the same sample as above)
• 6mm tape with h=32
• 6mm tape with h=34

Is that helpful?

[maresb]

That is very helpful, but I still don't understand what's going on. As far as I know, for all other printers we've seen the cartridge is irrelevant to the behavior of the printer. The printer just utilizes the full print head regardless of which type of tape is underneath.

Curiously the 12mm tape shows only rows 4-61, not 1-64, so there are 3 pixels missing from both the top and bottom of what would normally be a 64 pixel head.

The 6mm tape prints rows 18-47. Intriguingly this is 17 missing pixels from both the top and bottom.

@tomek-szczesny, do you have any thoughts on what could be going on with the hardware here?

[tomek-szczesny]

Assuming that both tape sizes are centered around the same line (which we pretty much take for granted for sizes at or below 12mm) , these test prints match what we would expect from 6mm printout without bottom side padding.

Padding used to be handled by the LUT that I introduced eons ago, but can't seem to find it now in the code..
Wasn't there some discussion about removing it in favor of some other solution?

Missing pixels on 12mm printout may be related to tape quality, and width of its inking ribbon.

[maresb]

@tomek-szczesny sorry I think there may have been some missing context. The test pattern should not be software-clipped, so row 1 of the test pattern should always correspond to pixel 1 of the print head in the sense of the raw data that we send to the printer.

So it seems to me like the device itself is clipping the printable area which I don't think I've ever seen before. Other printers would just print those pixels outside the borders of the tape.

[tomek-szczesny]

@maresb I forgot that test patterns are not padded, in which case these test prints are completely fine. I don't see anything suspicious about them.
All three test prints on the 6mm tape consistently have 17 dots missing on the bottom, which is what we expect.
The missing dots are a result of smaller tape, and even smaller ink ribbon.

@jgoerzen could you show us an example of a print that you attempted and was clipped from the bottom?
What brand of tape do you use?
Perhaps we just assumed too wide margins of error for this size of tape.

[maresb]

All three test prints on the 6mm tape consistently have 17 dots missing on the bottom, which is what we expect.
The missing dots are a result of smaller tape, and even smaller ink ribbon.

@tomek-szczesny I am confused why you expect this. My expectation based on previous experience (for example see here) is that there are no dots missing unless they physically extend past the boundary of the tape. Thus when the tape is smaller than the print head I expect no margin.

[maresb]

Also all the printed labels in the photo are clipped from the bottom since row 1 is missing despite that it would always fit on the tape.

[jgoerzen]

Missing pixels on 12mm printout may be related to tape quality, and width of its inking ribbon.

I have tried another 12mm cartridge and got the same result. It is possible I have a defective unit, I guess? I tried cleaning the printhead and that made no difference. These are Dymo D1 12mm labels, PN 1926208 as in https://www.dymo.com/labels-tapes/labelmanager-d1-tapes/dymo-d1-standard-labels-2-count/SAP_1926208.html

The 6mm cartridge is Dymo 43613 as from https://www.amazon.com/DYMO-Standard-LabelManager-cartridge-43613/dp/B000067SPT?th=1

[jgoerzen]

@jgoerzen could you show us an example of a print that you attempted and was clipped from the bottom?

Here is a photo from running:

labelle --tape-size-mm 6 ABCDEFGQ

on the 6mm tape:

[tomek-szczesny]

Okay, now I think we're discussing two different things, that's why we cannot find a common ground. :)

Indeed there is a gap between the lowermost dots and the lower edge of the printout. I think that this may be a result of either misaligned, or physically smaller ink tape inside the cartridge. @jgoerzen, could you take a look at the back side of a tape in the cartridge and see if the black ribbon isn't narrower than the tape?
What happens if you try to print text on 6mm tape, but with 12mm set in labelle? If 12mm printouts were fine, then it would be interesting to see what happens.

The second issue is that the printout is too low and doesn't fit. the "ABCDEFGQ" print looks like it misses padding, which should be about 17 dots. Even if the whole tape was printable, this text wouldn't fit.

[maresb]

could you take a look at the back side of a tape in the cartridge and see if the black ribbon isn't narrower than the tape?

Ohhhh, yes, that could explain it perfectly! I'm very curious now.

[tomek-szczesny]

I have a faint recall of this happening to someone in the past. I looked my only original Dymo cartridge and it doesn't seem to display such property.

[jgoerzen]

could you take a look at the back side of a tape in the cartridge and see if the black ribbon isn't narrower than the tape?

Interesting!

On the 6mm cartridge, the black ribbon is wider than the tape.

On the 12mm cartridge, the black ribbon is narrower than the tape.

This may explain the missing top/bottom pixels on the 12mm test image, I guess. But the black ribbon is actually wider than the 6mm tape.

Here is a photo from a 6mm cartridge with labelle --tape-size-mm 12 ABCDEFGQ:

[tomek-szczesny]

Now things get super weird. There seemingly is no physical limitation for printing across the full width of a 6mm tape, and yet, no matter what you do the edges remain blank.

I just googled LabelManager 280 and it's a hand held that you connect to a PC through USB, correct?
Then I suppose it is aware of the tape size because it asks the user about it after the lid is closed (at least my model 160 does that).
If this is true, then it may do some internal padding and cropping magic on its own. Our desktop label managers don't know what tape size they're dealing with, which made things easier for us.

I wonder if you could do the following and see if it works: Put 6mm cartridge, but tell the printer it's actually 12mm. If my line of thought is correct then Labelle should do correct prints, because your Dymo will behave like our PnP models.

[jgoerzen]

So I put in the 6mm cartridge, told the printer it was 12mm, and told labelle it was 6mm. The text moved up a bit -- an improvement -- but not enough:

[maresb]

Now things get super weird. There seemingly is no physical limitation for printing across the full width of a 6mm tape, and yet, no matter what you do the edges remain blank.

Now we're on the same page about this. 😃

Put 6mm cartridge, but tell the printer it's actually 12mm.

Another brilliant idea, thanks @tomek-szczesny! And it looked to me like it worked, since it now goes to the lower edge!

@jgoerzen, could you please use the following command for the test pattern from now on?

labelle --sample-pattern 34

I'm pretty sure that will reach the upper edge of the 6mm tape and we'll be good on that.

The margins on the 12mm tape are still a mystery to me though.

[jgoerzen]

OK, with the 6mm tape loaded, device set to 12mm, here are the 34 and 64 sample patterns:

[tomek-szczesny]

Thanks for your help and patience, @jgoerzen.

Now when we understand what is going on, we've got to decide on the solution to this problem.

The users will expect Labelle to work correctly with 6mm tape and the printer configured to 6mm. We can make this work through LUT or whatever we have right now, but with a big margin imposed by the printer's firmware.

Or we can instruct the users to putposefully misconfigure their devices and allow them to print larger content. Personally I don't like this idea at all.

I expected the 12mm mode to work correctly though, I'm not sure why it doesn't.

At the moment I'm taking care of my cat that had a surgery today so I can't inspect the samples more carefully.

[maresb]

Awesome!!! The 6mm tape corresponds to rows 10-51. ✔️ Now it's possible to handle this correctly with offsets.

@jgoerzen, no need to print any more size 34 sample patterns.

The only major remaining mystery is the 3 missing pixels on each side for the 12mm tape.

[tomek-szczesny]

The only major remaining mystery is the 3 missing pixels on each side for the 12mm tape.

John said that the inking ribbon is narrower than the tape, I would blame that.

Awesome!!! The 6mm tape corresponds to rows 10-51. ✔️ Now it's possible to handle this correctly with offsets.

If the printer is misconfigured to our advantage. Like I said I wouldn't want us to support this mode of operation, because it breaks compatibility with the official software and handheld operation of the device.
I believe we should stick to the capabilities offered by the device when it is configured properly, even if it means limited dot range.

This means different range and offsets for this particular printer model... Like I said before, I didn't find my LUT in the code, so I don't know how to handle that.

[maresb]

For reference, here's a photo of the tape in my 12mm cartridge:

Due to perspective and the black tape not being flush against the white tape, the gap looks much bigger than it is. It is actually roughly 0.5mm on each side, which is way smaller than the margin on the 12mm tape pictured above. Moreover, I have always been able to use the full 64 pixels of my LabelManager PnP print head.

@jgoerzen, in your 12mm printer cartridge, where the black ribbon is narrower than the tape: how does the width of the black ribbon compare with the printable height?

If the black ribbon is bigger than the printable area (like if it's within 1mm of each edge of the white tape), then the black ribbon is not the limiting factor.

If the black ribbon does coincide with the printable area, then we have different types of 12mm D1 cartridges and mine is not like @jgoerzen's.

[tomek-szczesny]

If not the tape limitations, this might as well be another restriction imposed by LM260 firmware. Nothing we can deal with I'm afraid.

[tomek-szczesny]

Like I said I wouldn't want us to support this mode of operation, because it breaks compatibility with the official software and handheld operation of the device.
I believe we should stick to the capabilities offered by the device when it is configured properly, even if it means limited dot range.

Further commenting on that, unless we find a way to read and write printer's settings through USB to hack our way around their cropping habits. That would improve the situation for tapes under 12mm at least.

[maresb]

Why not offer the option to access unsupported operation? For me this stuff is about giving people full access to the hardware, regardless of artificial restrictions imposed by the manufacturer.

BTW your LUT is here: https://github.com/computerlyrik/dymoprint/pull/91/files

We couldn't merge it because the code was too flaky to get it to work correctly. The code is less flaky, but still not ready to merge. There's an independent attempt at implementing a LUT in #65 but it still needs more work, started in #66, to avoid breaking stuff.

[jgoerzen]

I believe we should stick to the capabilities offered by the device when it is configured properly, even if it means limited dot range.

I should note that, with the 6mm tape, the Windows software prints correctly.

In an ideal world, yes, having Labelle work with the device set to 6mm mode would be best... but I can live with whatever works, if it's documented. Who am I to argue with some great Free Software? :-)

The only major remaining mystery is the 3 missing pixels on each side for the 12mm tape.

To be clear, I have no complaints about the 12mm mode with Labelle. Dymo's Windows software, in its default configuration, is cutting off on the top and the bottom in 12mm mode. Labelle isn't! Maybe it's just because fonts and QR code are different sizes by default, but in any case, I'm not having problems with the 12mm mode.

@jgoerzen, in your 12mm printer cartridge, where the black ribbon is narrower than the tape: how does the width of the black ribbon compare with the printable height?

I believe the black ribbon is indeed wider than the printable height.

If not the tape limitations, this might as well be another restriction imposed by LM260 firmware

I have a 420P on order and can test with it. I'll have a few days to test with them both side-by-side, so hopefully that will be enough to narrow down all of these and make both work (I note some similar conversation about it in #62)

Thanks again!

[jgoerzen]

I have swapped the 280 for a second one, in case mine was faulty. The result from it seems to be the same.

I also have a 420P to test with (I will need to return one of the 280 or the 420P to the shop soon; I can't actually use the 420P with Labelle right now because the 12mm is out of alignment due to #62 and develop branch crashes). I did a test with it as you can see. It looks to me that the 280 is unable to use the full width of the 12mm tape. Maybe that is really a 9mm printhead?

Here is a photo with both, with the 280 on top:

[tomek-szczesny]

I'll try to summarize my current beliefs on this topic, although to keep it brief I'll omit some explanation.

Even though the print related hardware between all mentioned Dymo models is largely the same (because they work with the same tape family D1), I think that 280P has limitations imposed by firmware or Windows software, or a combination of both.

PnP has 64-dot print head, or so we think as of today. I suspect that 280P has the same print head, because developing a slightly narrower model doesn't make much sense. Also our tests indicate that the print head is the same, because they accept data formatted the same way we send to PnP. I bet it's the firmware that crops away unwanted data. This is possible just because this printer IS aware of the tape size (provided by the user).

420P has larger 128-dot print head to support 19mm tapes. It also seems to have firmware level cropping mechanisms, as seen on the h=130 test print seen above. There are many possible explanations why this model allows for more content on 12mm tape. It could have been developed by a separate team that made different engineering decisions. It might have been a marketing decision to limit capabilities of 280P to justify higher price of other models - it's a standard practice these days.

To me it is clear that we cannot expect the users to use any of these printers with wrong settings to work around the firmware limitations. When the user unplugs the USB and goes into the field, they will have to reconfigure their printer each time.
Passing instructions to the user will be troublesome as well. How would they be supposed to know they should misconfigure their device to get Labelle to work?
The user will still be able to perform the same trick at their own discretion even if Labelle won't support it directly.

Based on all test prints collected above, we can figure out LUT values to support these printers. In other Issue someone had already posted a test pattern on a 19mm tape.

[jgoerzen]

I also just bought some 9mm tape to test with this. Results are encouraging. Here's the calibration:

When I leave Labelle at the default 12mm mode, it prints fine, though a little off-center towards the top. In 9mm mode, it prints off center towards the bottom, enough that it crops off a bit of the bottom. Both are with the labeler in 9mm mode.

Thanks again!

[tomek-szczesny]

@maresb, perhaps we should just let the users use custom offsets that override the built in ones, as a command line flag and GUI "advanced" option? Then more determined users could experiment on their own. :)

[tomers]

@maresb, perhaps we should just let the users use custom offsets that override the built in ones, as a command line flag and GUI "advanced" option? Then more determined users could experiment on their own. :)

Maybe have some sort of interactive calibration process, to guide users. It will print a sample, ask you which rows you see, what is the top and bottom gaps, etc., then it will print again, until the sample would align perfectly.

Could you write a document about this process, and I'll try to write such wizard?

[tomek-szczesny]

You got it, @tomers!
I created a new branch with my vision of the calibration wizard workflow.
Feel free to take over this branch.
All comments are welcome, especially correcting my inevitable grammar errors in the messages for the user.
https://github.com/labelle-org/labelle/blob/calib_wizard/doc/calibration-wizard.md

[ccdunder]

Curiously the 12mm tape shows only rows 4-61, not 1-64, so there are 3 pixels missing from both the top and bottom of what would normally be a 64 pixel head.

My 280 does the same thing on 12mm tape: exactly 3 pixels cut off from top and bottom.

Additional measurements from my 280:

• Printing from the printer itself, max print height is 1/4" on a 1/2" (12mm) tape.
• Printing via labelle, max height print height is 5/16" (on a 1/2" (12mm) tape).

[ccdunder]

Looks like the official dymo cups driver PPD for the 280 sets the max height to exactly 58 pixels. Probably not a coincidence.

Spec from PPD:

*ImageableArea w35h4000/12 mm (1/2") Continuous: "5.60 30.00 28.80 3970.00"
...
*DefaultResolution: 180dpi

Math:

# Note: the cups driver handles the page rotated by 90, so "right/left" margin is actually the top/bottom from user's pov.
(<right margin> - <left margin> / <points per inch>) * <DPI>

((28.8-5.6)/72)*180 = 58

[maresb]

Thanks a lot @ccdunder! That's a great idea to look in the PPDs. It's great to have confirmation that it's an apparent limitation. I didn't know the meanings of those numbers, so showing your math was extremely helpful!

The biggest obstacle at the moment is that we're working on a legacy codebase and we don't have the abstractions in place to support margins in a coherent way. There are intermittent efforts at getting there, currently contained in #82 and #65.