Printer stop before excute cut command

[kero43]

Hello
My problem is that sometimes the printer stops in the middle or the end of the paper before executing the cut command, and then it print garbage data if print anything. Is there a way to reset or clear the printer buffer before print new order, or a solution to the problem of stopping before the cut order that mentioned before?

printer stop here

garbage data next time

[kero43]

@lukevp

[nivle]

Try something like this?

using (SerialPrinter serialPrinter = new SerialPrinter(portName: "COM5", baudRate: 115200))
{
    EPSON epson = new EPSON();

    serialPrinter.Write(ByteSplicer.Combine(
        epson.PrintLine("test"),
        epson.FullCutAfterFeed(0)
    ));

    Thread.Sleep(100);
};

[kero43]

@nivle do you mean i should wait after every send data via socket because i have develop services and mobile apps(android and IOS) use it to get commands and send it chunk by chunk(height 256px) via socket
Thank you

[nivle]

@kero43 do you have a short example of your code, I myself had some issue with the regular cutting method, causing premature cuts, so I started using
epson.FullCutAfterFeed(0) and that seemed to work fine for me. The Thread.Sleep(100) there is there cus there is a weird issue where the printer does nothing without some amount of delay, I guess it takes a while until the code gets to the printer, so we don't want to destroy the object before it gets to the printer...

[kero43]

@nivle i will ask apps developers to wait 100 ms before send next commands and share the result
Thanks so much

[lukevp]

@kero43 you definitely need to provide a minimal sample that will reproduce the issue if you want more detailed help. In general though, the base printer's write methods are synchronous but they enqueue in a queue, they do not immediately write to the printer. The implementation will flush bytes to the printer every few milliseconds, and as soon as the printer accepts the bytes, it will send the next set.

For Epson printers, this works fine, because they hold the line open and don't accept the bytes if their buffer is full. However, the issue is when you get into 3rd party printers, they follow the ESCPOS protocol, but that protocol doesn't specify some implementation details like this, and it'll cause issues.

It's also possible that your printer doesn't fully support images, and you're trying to send images. In that case, you can use the legacy image mode.

Sleeping to write bytes slower is the type of solution that will probably work most of the time, but it might be flaky sometimes, so if you want to look into this issue in more detail, give us an example that reliably reproduces the issue and I'll help where I can. I can run it against my epson and non-epson printers and see how they behave.

[kero43]

hello @lukevp
I have API service that convert PDF files to ESC and mobile developers use it to send commands directly to printer via socket and everything is OK but some of non EPSON printers show garbage data although it start print correctly as mentioned before.
first, i think problem from buffer size but no effect.
second, i think from bad network and make mobile app waiting (from 50 to1000) ms but same issue
i will attach response to see ESC commands list(first for center, last for cutting and others for image chunks)

[lukevp]

Yeah, so the problem is likely a buffer overflow on the printer side, not on the computer hosting the program. EPSON printers are set up so they don't ACK a write unless their buffer has space, so the flush method will naturally wait until the buffer is empty, but a lot of 3rd party printers don't behave correctly in this situation.

Any time you see garbage data, what's typically happening is one of these 2 things:

1. you are printing images and your printers don't support the latest EPSON image printing protocol, which you can fix by using the legacy image printing methods, or
2. you're overflowing the buffer on the printer itself, and instead of rejecting / leaving the connection suspended while it clears the buffer out by printing data to the receipt paper, the printer just starts dropping bytes from the stream.

The reason #2 results in garbage data is because your printer starts interpreting the byte stream with missing ESC commands, so it starts interpreting images as text, etc, because it misses the ESC sequences that tell the printer to switch into image / barcode / QR code printing mode.

I would first double-check that you're not running into issue #1 by switching to legacy image mode if possible. If that doesn't help, then I would try and definitively determine if #2 is your issue. One way you could verify if this is the issue is doing the following:

• accept writes from your client
• store the writes into a list in your code
• implement a loop that does the following:
  • send the first up to 1000 bytes in your list to the printer
  • sleep for 1000 ms
  • as long as you still have bytes in the buffer, repeat the above until the list is drained.

If this solves your garbage data, then the problem is a buffer overflow on the printer side. 1000 bytes per second is a super slow data rate for these printers, so if you're still seeing garbage data, then something else is wrong with your ESC commands.

Testing by putting a sleep between entire requests isn't sufficient for testing this, because the problem may be the underlying printer hardware, so you need to throttle the actual byte stream you're sending to the printer.

Let me know what the outcome is of these tests and I'll see if I can point you to the next thing to try.

[kero43]

Thanks @lukevp
I will ask mobile developers to try #2 because i am using legacy mode and get feedback from them.

[nivle]

@kero43 How big are your image chunks?(in width and height px) from my experience, my printer did similar things as to what you're describing when my image width was greater than 512px(which is 2x 256), then my printer started printing the image slower, in chunks, and sometimes failed and printed weird stuff(prob cus of buffer issues). I fixed that issue as described here.