Question: Compatibility with M220

[5263]

I recently got an M220 and tried it with the M110 driver.
I found out that the M220 treats every GS v 0 as a separate print job introducing line feed and back feed resulting in a gap of approx. 6 mm.
I discovered that the M220 supports at most 1200 lines per GS v 0 command. Limiting the maximum printable size to 72 mm x 150 mm

[daig0rian]

Thanks for the report. Is this printed in continuous paper mode in the cups driver for the m110?

Actually when I made the change to support continuous paper in the filter for the m110 I did not test it because I do not have continuous paper. So it is possible that the same thing could happen with the m110. When the continuous paper arrives I will test it.

[5263]

Thank you for your quick reply and all your effort for this project.
Yes, this was printed in continuous paper mode (selected via CUPS, as well as set as default in the printer settings.)

[daig0rian]

Hmmm, I tried it on my M110 and it prints fine.

Here is what I did
CUPS installation without phomemo backend.
(The phomemo backend still doesn't work well with non-M02/M110 discovery, so here I used the serial backend to specify the device file path)

sudo lpadmin -p M110 -E -v serial:/dev/usb/lp1 -P /usr/share/cups/model/Phomemo/Phomemo-M110.ppd.gz 

Prepare a 100 x 600px portrait image.

Print it with the following command.

lp -d M110 -o Media=Custom.50x300mm -o MediaType=Continuous grid_100x600.png

And the result looks like this image.

It should be noted that the default options for the M110 CUPS driver have the following values.

Media Size: w 40mm h 30mm
Media Type:  "Label With Gaps"

This can be checked with the following command

$ lpoptions -d M110 -l
PageSize/Media Size: w20h100 w20h10 w20h20 w25h10 w25h30 w25h38 w30h20 w30h25 w30h30 w35h15 w40h20 *w40h30 w40h40 w40h60 w40h80 w45h60 w50h20 w50h30 w50h50 w50h70 w50h80 Custom.WIDTHxHEIGHT
Resolution/Resolution: *203dpi
ColorModel/Color Mode: *Gray
MediaType/Media Type: *LabelWithGaps Continuous LabelWithMarks

So if you want to print on continuous paper with the M110 driver, you need to specify the option explicitly.

[daig0rian]

The results of a test print with GUI are also shown below.

(I tested with the largest label size, as it does not appear to be possible to set a custom page size in the GUI at this time. I would like to modify the GUI to allow setting custom page size, but I don't know how.)

[daig0rian]

From the Phomemo m220 manual I can confirm that the m220 is 203dpi, so if the m220 can only print 1200 lines at a time, the maximum print size would be approximately 5.9inch (15cm) high.
@5263
Can the vendor-supplied m220 driver print longer than that? For your information, the vendor's smartphone application for the m110 has a maximum print size of 300mm (30cm) in height.

[5263]

I ran the two commands

lpadmin -p M110 -E -v serial:/dev/usb/lp1 -P /usr/share/cups/model/Phomemo/Phomemo-M110.ppd.gz
lp -d M110 -o Media=Custom.50x300mm -o MediaType=Continuous grid_100x600.png

Please see the gaps in the picture.

[bleriotx]

I can also confirm there is an issue with the M220 using the Phomemo-M110.ppd.gz. The printer refuses to print anything longer than a 40mm label without sending a form feed (Gap label paper) . I installed the lame Labelife app from Phonemo on a spare Win10 laptop and it can print a 50mm X 80mm label without any issues.

So, there is something different about the way the M220 processes print jobs.

Let me know if you want me to run any specific tests to troubleshoot the issue.

B

[daig0rian]

The code that sends out a GSv0 command every 255 lines seems like it should be eliminated, even on the M110.
I captured a USB packet printing a 50mm x 300mm continuous paper with M110s in Labelife, the Windows app, and the GSv0 command appeared only once.
packets_M110S_50mmX300mm.zip

Summary of problem with gaps every 255 pixel rows on M220

• The current rastertopm110.py outputs a GS v 0 command every 255 pixel lines. This is the code copied from M02.
• The M110s does not have a problem with GS v 0 commands every 255 pixel lines.
• On M220s, a GS v 0 command every 255 pixel lines causes a gap. A continuous print with a height of 300mm = approx. 2397 pixel rows will gap 9 times.
• The official Windows application "Labelife" sends only one GSv0 command, even if the image has 2398 pixel lines (300 mm high).

[daig0rian]

@bleriotx
Could you please get the USB packet from printing on a 50mm X 80mm label using M220 with Labelife on your Win10 laptop?
Here are the capturing steps.

1. Install a wire shark
2. Configure USB Pcap, uncheck the three checkboxes and check the printer device.
3. Start the capture
4. Print the laberl.
5. Save the result, zip it and stick it to this issue.

[bleriotx]

Here you go!

M220.zip

My M220 pcap confirms what you found. The Labelife Windows app only sends on GSV0, at the beginning of the print data.

Let me know what else you need.

Appreciate the fast response.

B

[bleriotx]

I did some pcap analysis and wrote up my findings.
Caution: I am not a CUPS wizard, so I am clearly out of my comfort zone. ;)

M220_bug_writeup.pdf

B

[bleriotx]

I was able to get a good 50x80mm print on my M220.

@daig0rian was correct - the CUPS filter was breaking up the image into 255 line segments instead of sending the whole image at once to the printer.

I modified the CUPS filter file (/usr/lib/cups/rastertopm110).

Comment out the original code on line 123:
''' with os.fdopen(sys.stdout.fileno(), "wb", closefd=False) as stdout: print_header(stdout,header.cupsMediaType) while line < im.height: lines = im.height - line if lines > 255: lines = 255 print_raster(stdout, im, line, lines) line += lines print_footer(stdout) '''
Replace it with this:
with os.fdopen(sys.stdout.fileno(), "wb", closefd=False) as stdout: print_header(stdout,header.cupsMediaType) lines = im.height print_raster(stdout, im, line, lines) print_footer(stdout)

I can now print a test page correctly on a 50x80mm label.

I will continue to test to make sure this fixes the printing on large labels.

B

[daig0rian]

@bleriotx Thanks for the great research and testing.
Would you consider forking this repository to your account and sharing your modified code with us?
It has the following advantages

• I can test your code on my M110 as well.
• After testing, Vivier can merge your pull requests and you will be recorded as a contributor.

[daig0rian]

@bleriotx I also checked your two files.
About M220.zip
We were able to confirm that M110 and M220 have exactly the same format, down to the header, raster image, and footer. This confirms that M110 and M220 are compatible, which I feel is a great accomplishment in that we now understand that there is no need to separate the two filters.

About M220_bug_writeup.pdf
You pointed out that there is an unnecessary "ESC @". My understanding is that the M110 also does not need this signal, so it is better to remove it from the code.　

[bleriotx]

@daig0rian I forked the project and created a pull request.
Hope I did it right...

B

[bleriotx]

After further testing, I am satisfied the modifications made to the CUPS filter make it compatible with the M220.
I generate a PDF file in Python using the excellent ReportLab module. I then push it to the M220 using the pr CLI. Works great.

NOTE: I do not have an M110 so I do not know if this broke compatibility.

B