Back in 2012, in my never-ending quest to geek up Tuihana Cafe, I threw together a Windows based app that takes SMS messages and prints them out on our kitchen receipt printer (read about it here). It allows our customers to make an order on their way to the cafe, without having to stand around and wait for the coffee to be made.
All was right in the world… or so I thought.
Late last year I decided to learn ESC/POS and print directly to the receipt printer, rather than continue cheating by using the Epson .Net OPOS drivers. This introduced a very annoying bug:
For some reason, the receipt printer or my program was adding in random characters (such as the speech marks before Printed, and the bracket before Sender) and dropping characters (like the O from the word One). My staff were clever enough to decipher these messages, however this wasn’t completely bulletproof – an order came through for 1x flat white, but the system printed out 21x flat white. It was then I new that I had to fix this once and for all.
For the last month I’ve been working on a fix, and it wasn’t until today that I stumbled across a blog post with the solution.
BinaryWriter has a method .Write() which takes a string as the input parameter. Instead of just appending this to the internal buffer, it also (not helpfully) prepends the length of the string in the first byte.
From the blog post:
Now that I think about it, this makes perfect sense: strings in the .NET framework are typically not thought of as being null-terminated, they’ve got a length, and in order for theBinaryReader‘s Read(string) method to work, it’ll need to be able to know the length of the string to determine how many bytes to read.
In my case, I was writing data to an Epson TM-T88III receipt printer, and given the structure of the commands that the printer expects, it doesn’t need or want the length of the string in this way. Because I didn’t read the MSDN documentation closely, I was left scratching my head as to why weird characters were showing up or characters were being omitted in my output.
The solution? Replace .write(“Test”) with .write(Encoding.ASCII.GetBytes(“Test”))
The new receipts all fixed up and looking purdy:
Hopefully this helps someone out from weeks of frustration and programmer rage.
Other related posts:
eWay response codes as a file
Extending Xero through their API
User accessibility, and keeping the bad guys out
comments powered by Disqus