Image printed only partially #3
Comments
|
@davidrothb that's strange... It printed fine on B21 and USB connection. Are you using bluetooth or USB? 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. the source image is not that great for determining which part is actually printed but the same print area cutoff is visible |
|
@davidrothb I added |
|
python3 niimprint -m b1 -a COM15 -i examples/test.png -v |
|
Also having the same issue on the B1 but printer with rotation 0. Seems to only print the first ~200 pixels of the image. |
|
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. |
|
@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 after sending the image in packets, end_page_print() is called which starts the printing process itself; i added a wait for input between those blocks just to have control over when packets are sent, now the log looks like this 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 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 and got this for the first test print this one for the second this one with manually caused error by opening the printer while printing towards the start of the print this one with error caused halfway in and this one with an error towards the end the pattern i see here is, based on index in the array it works great
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!
|
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
The text was updated successfully, but these errors were encountered: