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.
NZ Tech Podcast 193: A visit to Ford Research, Samsung Galaxy Alpha, Tesla’s unlimited warranty
I got the confirmation I will be attending the TechEd as a Microsoft guest (same as in previous years) with other media presence.
In the meantime, I have just finished working on something with Intergen for their stand - you folks probably remember in previous years there were racing cars and the stand was quite popular.
This year, working with Microsoft Xbox and Activision there will be Guitar Hero competition - prizes include daily JB Hi-Fi voucher and a Xbox One with Kinect at the end of the competition. More information here: Intergen Guitar Hero Geek competition at TechEd.
NZ Tech Podcast 192: China cracks down on online rumours, Sony 4K/UHD TV iPhone 6, Renaissance to liquidate
NZ Tech Podcast 190: NZ’s Electron rocket, the selfie toaster, Skinny’s HTC Desire 310, Microsoft China raided
NZ Tech Podcast 189: LG G3 hands on, Vector fibre network grows, China’s $15 wearable, 60-million iPhone 6 handsets in production?
Externally it looked ok.
Not too much dust.
After opening noticed little black streaks all over the place.
Identified as cockrock feces.
Sure enough I spotted some live ones chilling out on the ram.
I wonder how manymore I will find toasted in the power supply.
Mechanically they would be worlds better than the plastic kids ride on toys you can get.
I wanted a 4 wheel model, 3 just wasn't going to cut it.
Picked up one for $100 ish.
Cosmetically it was a little rough.
Batteries were dead.
Controller had a fault.
The important bits were ok.
Frame, Motor, Tyres.
Due to the age of the system, there was not many troubleshooting documents to be found on the interweb.
I also wanted to run it at 36V, which the stock controller would not be happy with.
Going diy you do loose some of the nice built in features of the controller, unless you buy another with those features.
-Over current protection.
-lots of others
Something with these features is about us$230 landed
The controller was stripped down to see what was inside.
12 years old? Look's like new :)
H-Bridge Mosfets were rated to 60V. P60NE0
There were 2 Driver ICs. ir2104
We will be able to reuse this part of the controller.
The drivers make it much safer on the hobbyist since you can't short the battery by setting the wrong Mosfets on.
There was a voltage regulator onboard (7805) but I could not easily figure out how to turn it on.
And didn't want to risk breaking anything else on the board in case I want to use it later on.
Cut the signal traces to the H-Bridge drivers.
Supply control signals and whola.
Working motor controller.
LM317, might bump it up to 15v.
Or change for a DC-DC to maximise efficiency.
-Arduino ProMini v2 (Clone, m168)
-Pedals from a computer steering wheel racing set.
-Battery will be a Lithium Polymer (LiPo) pack from Hobbyking.
us$116 landed for a 33.3v(9s) 5.8Ah
Top speed should be 15-20kp/h
At low speed for the kids we should get 30-45 mins runtime.
Currently the program on the Arduino is pretty simple.
Push accelerator pedal to go.
Let go to coast.
Push brake to stop.
To potentially add
Pretty simple in code.
Just need to add a switch.
Low speed with a 10 second full speed boost available every few minutes.
Make racing interesting.
-Adjustable max speed.
So multiple carts can be set to the same max speed.
During a race it will be driver skill that determines the winner.
Other people have put petrol motors in theirs.
I stayed with electric to keep the noise/maintenance/risk down.
A friend is helping with the metalwork/fabrication side.
Can do a more detailed write up if 3+ GZ members are interested. :)