niimprint
niimprint copied to clipboard
AndBondStyle
Image printed only partially
I'm using niimbot b1, the source image is 320x480px in size.
As per photo, it seems like only the top third of print area is used. The label size is 40x60mm
@davidrothb that's strange... It printed fine on B21 and USB connection. Are you using bluetooth or USB? Update: tested with bluetooth, also works fine :thinking:
I also noticed your image is printing bottom-to-top instead of top-to-bottom. Can you show me the command you're running?
@AndBondStyle i was using USB. i tried firstly with the image source horizontal and -r 90, then rotated source image without -r, lastly rotated source with -r 180; then i noticed it was useless debugging when pillow is doing the image work
the source image is not that great for determining which part is actually printed but the same print area cutoff is visible
the image from examples is visible as well, same thing with the "cutoff"
@davidrothb I added --verbose flag for the CLI, can you try to run the script again and attach the logs?
@AndBondStyle
python3 niimprint -m b1 -a COM15 -i examples/test.png -v
DEBUG | PngImagePlugin:call:190 - STREAM b'IHDR' 16 13
DEBUG | PngImagePlugin:call:190 - STREAM b'gAMA' 41 4
DEBUG | PngImagePlugin:call:190 - STREAM b'iCCP' 57 1038
DEBUG | PngImagePlugin:chunk_iCCP:393 - iCCP profile name b'kCGColorSpaceGenericRGB'
DEBUG | PngImagePlugin:chunk_iCCP:394 - Compression method 0
DEBUG | PngImagePlugin:call:190 - STREAM b'cHRM' 1107 32
DEBUG | PngImagePlugin:call:190 - STREAM b'eXIf' 1151 120
DEBUG | PngImagePlugin:call:190 - STREAM b'pHYs' 1283 9
DEBUG | PngImagePlugin:call:190 - STREAM b'iTXt' 1304 345
DEBUG | PngImagePlugin:call:190 - STREAM b'IDAT' 1661 13825
DEBUG | printer:_log_buffer:146 - send: 55:55:21:01:05:25:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:31:01:01:31:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:23:01:01:23:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:33:01:01:33:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:01:01:01:01:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:02:01:01:02:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:03:01:01:03:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:04:01:01:04:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:13:04:01:e0:01:40:b7:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:14:02:01:00:17:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:e3:01:01:e3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:00:c7:01:16:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:01:8f:01:5f:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:01:df:01:0f:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:e4:01:01:e4:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:f3:01:01:f3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:f4:01:01:f4:aa:aa
Also having the same issue on the B1 but printer with rotation 0. Seems to only print the first ~200 pixels of the image.
DEBUG | PngImagePlugin:call:190 - STREAM b'IHDR' 16 13
DEBUG | PngImagePlugin:call:190 - STREAM b'iCCP' 41 389
DEBUG | PngImagePlugin:chunk_iCCP:393 - iCCP profile name b'ICC profile'
DEBUG | PngImagePlugin:chunk_iCCP:394 - Compression method 0
DEBUG | PngImagePlugin:call:190 - STREAM b'bKGD' 442 6
DEBUG | PngImagePlugin:_open:726 - b'bKGD' 442 6 (unknown)
DEBUG | PngImagePlugin:call:190 - STREAM b'pHYs' 460 9
DEBUG | PngImagePlugin:call:190 - STREAM b'tIME' 481 7
DEBUG | PngImagePlugin:_open:726 - b'tIME' 481 7 (unknown)
DEBUG | PngImagePlugin:call:190 - STREAM b'tEXt' 500 25
DEBUG | PngImagePlugin:call:190 - STREAM b'IDAT' 537 8189
DEBUG | printer:_log_buffer:146 - send: 55:55:21:01:05:25:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:31:01:01:31:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:23:01:01:23:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:33:01:01:33:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:01:01:01:01:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:02:01:01:02:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:03:01:01:03:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:04:01:01:04:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:13:04:00:f0:01:80:66:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:14:02:01:00:17:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:e3:01:01:e3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:00:c7:01:16:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:00:ef:01:3e:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:e4:01:01:e4:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:f3:01:01:f3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:f4:01:01:f4:aa:aa
I've done a bit more testing with this and my B1 over USB. When running with the default density of "5", I lose the bottom half of the print. Density "4" is the same. When running on density "3", its hit or miss whether I get a full print. Setting density to "2" or "1" seems to work every time.
Given that it takes noticeably longer to transmit the higher density file over USB, I'm wondering if its either a timing issue with the printer or the internal buffer becoming full?
@alexmoras interesting observation... I always assumed the "density" is just an amount of time/heat the printer applies to each pixel. On the protocol level it's exactly the same image and exactly the same amount of data being transmitted. Just out of curiosity, can you try printing via bluetooth?
Okay fair shout - I've got to get my head out of the "normal" printer concept. I think you're right with it just being the amount of time heat is applied.
Tried via Bluetooth and regardless of the image density, I get maybe 50 lines printed and that's about it. Never any more. There seems to be something funky going on with the serial connection. I'm wondering if the printer "times out" after X amount of milliseconds and cuts off the print. Maybe this is more noticeable with the higher density is that it takes longer to print. Again with the BT connection, since the connection is slower it times out "earlier"? Just a theory. I'll have to do some more digging.
python niimprint -m b1 -c bluetooth -a 05:13:F9:XX:XX:XX -d 5 -i /home/alex/Documents/test.png --verbose
DEBUG | PngImagePlugin:call:190 - STREAM b'IHDR' 16 13
DEBUG | PngImagePlugin:call:190 - STREAM b'iCCP' 41 389
DEBUG | PngImagePlugin:chunk_iCCP:393 - iCCP profile name b'ICC profile'
DEBUG | PngImagePlugin:chunk_iCCP:394 - Compression method 0
DEBUG | PngImagePlugin:call:190 - STREAM b'bKGD' 442 6
DEBUG | PngImagePlugin:_open:726 - b'bKGD' 442 6 (unknown)
DEBUG | PngImagePlugin:call:190 - STREAM b'pHYs' 460 9
DEBUG | PngImagePlugin:call:190 - STREAM b'tIME' 481 7
DEBUG | PngImagePlugin:_open:726 - b'tIME' 481 7 (unknown)
DEBUG | PngImagePlugin:call:190 - STREAM b'tEXt' 500 25
DEBUG | PngImagePlugin:call:190 - STREAM b'IDAT' 537 8189
DEBUG | printer:_log_buffer:146 - send: 55:55:21:01:05:25:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:31:01:01:31:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:23:01:01:23:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:33:01:01:33:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:01:01:01:01:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:02:01:01:02:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:03:01:01:03:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:04:01:01:04:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:13:04:00:f0:01:80:66:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:14:02:01:00:17:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:e3:01:01:e3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:00:c7:01:16:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:d3:03:00:ef:01:3e:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:e4:01:01:e4:aa:aa
DEBUG | printer:_log_buffer:146 - send: 55:55:f3:01:01:f3:aa:aa
DEBUG | printer:_log_buffer:146 - recv: 55:55:f4:01:01:f4:aa:aa
@alexmoras i´ve tried the density settings on my printer, with -d 1 i can get it to print slightly more than half of the sticker, but never more; other density options make it worse
Okay I think that confirms there's something untoward going on with serial / timing in the printer. I'm working this week but will try and have a look on the weekend.
I'm wondering if it's something to do with the "end print" packet being sent too early or some form of race condition over serial where the end print packet ends up higher in the printer's buffer than the rest of the image. I'll have a read of the upstream project which contains a wiki with the breakdown of the packet structure.
@alexmoras can you share the protocol wiki link? I'll also have a look. Unfortunately right now I don't know how to help you, the only way is to go and buy a B1 for myself...
Only details I have are the ones from the forked repo - https://github.com/kjy00302/niimprint/wiki/Line-encoding-packets
When I get five minutes I'll try and sniff the data being sent / returned whilst watching the printer buffer and see if I can't decode it.
i´ve finally managed to repeatedly print the test image with all density settings
https://github.com/AndBondStyle/niimprint/blob/2199e655889fc1cc52d1f255cad4f79afa20f9de/niimprint/printer.py#L111C2-L116
after sending the image in packets, end_page_print() is called which starts the printing process itself; after 0.3s end_print() is called by the while loop and whatever it returns, it stops the print and makes the printer align the label for cut
i added a wait for input between those blocks just to have control over when packets are sent, now the log looks like this
python3 niimprint -a COM15 -d 5 -i examples/test.png -v
DEBUG | PngImagePlugin:call:190 - STREAM b'IHDR' 16 13
DEBUG | PngImagePlugin:call:190 - STREAM b'gAMA' 41 4
DEBUG | PngImagePlugin:call:190 - STREAM b'iCCP' 57 1038
DEBUG | PngImagePlugin:chunk_iCCP:393 - iCCP profile name b'kCGColorSpaceGenericRGB'
DEBUG | PngImagePlugin:chunk_iCCP:394 - Compression method 0
DEBUG | PngImagePlugin:call:190 - STREAM b'cHRM' 1107 32
DEBUG | PngImagePlugin:call:190 - STREAM b'eXIf' 1151 120
DEBUG | PngImagePlugin:call:190 - STREAM b'pHYs' 1283 9
DEBUG | PngImagePlugin:call:190 - STREAM b'iTXt' 1304 345
DEBUG | PngImagePlugin:call:190 - STREAM b'IDAT' 1661 13825
DEBUG | printer:_log_buffer:154 - send: 55:55:21:01:05:25:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:31:01:01:31:aa:aa
DEBUG | printer:_log_buffer:154 - send: 55:55:23:01:01:23:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:33:01:01:33:aa:aa
DEBUG | printer:_log_buffer:154 - send: 55:55:01:01:01:01:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:02:01:01:02:aa:aa
DEBUG | printer:_log_buffer:154 - send: 55:55:03:01:01:03:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:04:01:01:04:aa:aa
DEBUG | printer:_log_buffer:154 - send: 55:55:13:04:01:e0:01:40:b7:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:14:02:01:00:17:aa:aa
waiting for key press before end_page_print()
DEBUG | printer:_log_buffer:154 - send: 55:55:e3:01:01:e3:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:d3:03:00:c7:01:16:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:d3:03:01:8f:01:5f:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:d3:03:01:df:01:0f:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:e4:01:01:e4:aa:aa
waiting for key press before end_print()
DEBUG | printer:_log_buffer:154 - send: 55:55:f3:01:01:f3:aa:aa
DEBUG | printer:_log_buffer:154 - recv: 55:55:f4:01:01:f4:aa:aa
and sure enough, on the first stroke the label is printed, on the second stroke it is fed a bit to align with the cutter if you hit the second stroke too early, printing is stopped and the label aligned
TLDR: the end print packet has priority over the buffered data, if it is sent too early, the label does not come out fully printed
i´m not sure if the printer prints always with the same speed, if yes, adding a static delay between end_page_print() and end_print() would fix the issue, but being able to check the status would be better, i noticed the get_print_status func, might take a look at it tomorrow
okay so printing a fully dark image is obviously slower, the print status has to be checked instead of using a static delay
Oh awesome! Nice find!
Yeah I think we'll have to check the print status before ending the print owing to different label/print sizes.
I'll also have a go if I get a chance when I finish work later.
i´ve converted the byte array the printer returns when asked for state to an int array
packet = self._transceive(RequestCodeEnum.GET_PRINT_STATUS, b"\x01", 16)
int_values = [x for x in packet.data]
and got this for the first test print
[0, 0, 20 , 0 , 1, 158, 0, 1, 0, 0]
[0, 0, 58 , 0 , 2, 89 , 0, 1, 0, 0]
[0, 0, 97 , 0 , 3, 19 , 0, 1, 0, 0]
[0, 1, 100, 100, 3, 30 , 0, 2, 0, 0]
[0, 1, 100, 100, 3, 30 , 0, 2, 0, 0]
this one for the second
[0, 0, 20 , 0 , 1, 159, 0, 1, 0, 0]
[0, 0, 58 , 0 , 2, 86 , 0, 1, 0, 0]
[0, 0, 95 , 0 , 3, 10 , 0, 1, 0, 0]
[0, 1, 100, 100, 3, 30 , 0, 2, 0, 0]
[0, 1, 100, 100, 3, 30 , 0, 2, 0, 0]
this one with manually caused error by opening the printer while printing towards the start of the print
[0, 0, 19, 0, 1, 156, 0, 1, 0, 0]
[0, 0, 43, 0, 2, 13 , 1, 0, 0, 0]
[0, 0, 43, 0, 2, 13 , 1, 0, 0, 0]
[0, 0, 43, 0, 2, 13 , 1, 0, 0, 0]
[0, 0, 43, 0, 2, 13 , 1, 0, 0, 0]
this one with error caused halfway in
[0, 0, 20, 0, 1, 158, 0, 1, 0, 0]
[0, 0, 57, 0, 2, 84 , 0, 1, 0, 0]
[0, 0, 90, 0, 2, 238, 1, 0, 0, 0]
[0, 0, 90, 0, 2, 238, 1, 0, 0, 0]
[0, 0, 90, 0, 2, 238, 1, 0, 0, 0]
and this one with an error towards the end
[0, 0, 20 , 0 , 1, 158, 0, 1, 0, 0]
[0, 0, 58 , 0 , 2, 87 , 0, 1, 0, 0]
[0, 0, 96 , 0 , 3, 12 , 0, 1, 0, 0]
[0, 0, 100, 66, 3, 30 , 1, 0, 0, 0]
[0, 0, 100, 66, 3, 30 , 1, 0, 0, 0]
the pattern i see here is, based on index in the array
0 - always 0
1 - 1 when printing has finished
2 - probably a percetage value
3 - 100 when printing has finished (might be whole-job percentage when printing multiple labels)
4 - ?
5 - ?
6 - turns to 1 when error occurres
7 - turns to 0 when error occurres
8 - always 0
9 - always 0
it works great
{'status': 0, 'progress': 19, 'error': 0}
{'status': 0, 'progress': 57, 'error': 0}
{'status': 0, 'progress': 86, 'error': 1}
{'status': 0, 'progress': 86, 'error': 1}
{'status': 0, 'progress': 86, 'error': 1}
python3 niimprint -a COM15 -i examples/test3.png
Printing...12%
Printing...51%
Printing...91%
Print job finished
let me know if you found a better way to do this
Just for reference sake I experienced the same behaviour on B21, thank you very much for debugging this, it helped a lot!
