Need a printer on my AVR app...

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An app requires adding a hard-copy capability.  Think of a "batch ticket" that gives date/time/amount/moon phase/etc.

 

AVR has an available USART port, that we can turn into RS232 or RS485 or ...

 

We did find one RS232-to-USB adapter that we are going to try, that claims to be for this task.  ("cheap" printers seem to be USB...)

 

Yeah, the cheap printers often have wireless but I think I'd try to avoid it in this particular industrial environment.

 

So I get a cheap printer -- what commands do I send it?  Do I need to develop a "driver"?

 

LOL -- 15+ years of doing AVR8 apps, and the first time for hard-copy.  All others send e.g. log files to a PC and then reports from there.

 

A first look at cheap printers leads us to small laser (to avoid inkjet mess/smearing).  But perhaps some POS terminal printer would work as well -- probably don't need a full page. 

 

Ideas?  Suggestions?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm no hardware expert (as you know!) but aren't those kind of "ticket" things usually done on a small thermal device rather than anything as fancy as a laser? Even today when I buy groceries my receipt is on thermal paper. The further advantage is that apart from the paper there aren't other "consumables" so you don't have to keep replacing ink or toner or print-heads or the like. Also the fact that every supermarket in every town in every country on planet earth probably has 20..50 such printers probably means there's both (a) competition in the manufacture and (b) economies of scale.

 

(just the rambling thoughts of an idiot by the way ;-)

 

EDIT: quick Goolge seems to suggest Seiko-Epson may be the world leaders in this game.

Last Edited: Thu. Apr 21, 2016 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okidata still offers impact printers with optional serial interfaces for POS and industrial use, for example this one.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
aren't those kind of "ticket" things usually done on a small thermal device rather than anything as fancy as a laser?

Awaiting feedback from the end customer about thermal strip acceptability.  That would be the most straightforward interface as many models have serial+USB.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the customer balks at the notion of narrow rolls of flimsy receipt paper, there are other thermal alternatives:

https://www.google.ca/search?q=ticket+printer

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a long time since I last dabbled in printer drivers (getting on for 30 years - eek!) but back then the common interface was, of course, "centronics parallel" and the common driving codes were "FX80". So you used ESC '4'  to turn italic on and ESC '5' to turn it off and so on. The printer itself had "font roms" (a bit like HD44780 still do for LCD) so you could pretty much just send ASCII with the odd "bold" or "italic" escape thrown in for good measure - if you wanted to get fancy and print a logo or something you could use ESC '*' ( I thin kit was then send some dot patterns).

 

Problems came later when even the simplest dot matrix and inkjet ditched the idea of internal character set ROMs and applying things like bold and italic to their own font definitions locally and instead changed to just using "page description languages" like Postscript, subsets/workalikes and so. This moved the "intelligence" of the printer out of the printer itself and into the driver on the PC that was driving it (so probably a Windows GDI driver). The Windows driver would then form a pixel image of the entire page on the PC/driver side and just effectively print nothing but dots and make head movements in the mechanism itself. This was a cost saving exercise for the printer manufacturers because, as everyone knows, software costs nothing but it did rely on the host being something powerful like a PC with oodles of RAM to form the page/dot images to be sent. But it made it difficult/impossible to add a simple printer interface to a small, embedded 8bit micro solution.

 

I wonder if these printers are like that these days? Because, if so, the problem is not going to be so much the physical hardware interfacing (USB or whatever) but the development of printer drivers that can work in a K or two in an AVR. Hopefully you can find printers with "intelligent" on-board controllers that have all the font ROMs and stuff within the printer because otherwise you end up having to hold that in the driving micro and in its very limited RAM to put things together.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

'twas was a very long time ago, but in the DOS days apps had their own printer drivers. Depending on the complexity of the printout you can possibly get away with a not too elaborate driver. Last time I looked there still was laser-printers with e.g. Epson-emulation (admittedly that was also a while back...)

 

How long do the printouts need to last?  (Thinking of the archiving-unfriendlieness of thermal prints).

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

It's a long time since I last dabbled in printer drivers (getting on for 30 years - eek!) but back then the common interface was, of course, "centronics parallel" and the common driving codes were "FX80". So you used ESC '4'  to turn italic on and ESC '5' to turn it off and so on. The printer itself had "font roms" (a bit like HD44780 still do for LCD) so you could pretty much just send ASCII with the odd "bold" or "italic" escape thrown in for good measure - if you wanted to get fancy and print a logo or something you could use ESC '*' ( I thin kit was then send some dot patterns)....

I believe the Oki printer I linked to earlier, which has been around in one form or another for decades, supports the Epson command set you remember. I am amazed the printer is still around. I write "believe" because I wrote end-of-job reports and such for other brands (e.g., DEC and TI).

- John

Last Edited: Thu. Apr 21, 2016 - 06:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

what commands do I send it?

Well, back in the day, before moving the "driver" to the PC as Cliff outlined above, one just sent ASCII to the printer.

That is where CR and LF came from, (1/2 truth).

 

Sometimes the printer was "smart enough" to accept an esc code for 10 characters/inch or 12 characters/inch, etc.

 

This, in fact, is what one would generally send the small thermal receipt printers.

 

Digikey lists several printers, this is the first one, a thermal print, 2 inch wide paper, 5 V interface 450 dots/line.

I didn't look at the spec sheet to see if you can drive it with ASCII data, or if you have to go one step lower and feed it the dot patterns for each line of print.

This one is $63 USD each.

I think I've seen them for under $50.

 

JC

 

The little printers certainly exist, and the application that I've seen them used in most recently was in the rental car return process, where the individual checking in the car held a handheld "terminal" (keyboard, GLCD, and printer), and printed out a receipt for the customer on narrow width paper.  The last one's I recall were actually impact printers, with inked receipts, not the thermal paper. 

 

JC

 

OK, here is a < $50 USD small quantity thermal printer, from Spark Fun.  It uses a 1.5" wide paper spool, and has a 19200 baud serial interface.

Perhaps a decent option to get a working prototype / concept model up and running quickly.

 

JC

 

 

 

Last Edited: Thu. Apr 21, 2016 - 06:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd imagine it can't be terribly difficult if there's an arduino library:

https://github.com/adafruit/Adaf...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The small POS (no, not _that_ POS) printers can also be had in impact form, if thermal printers are not acceptable.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Notes after a bit of poking about:

-- Yes, there is typically a sort of simple protocol to e.g. select font size in receipt printers.  For simple work should be able to easily make a driver.

-- Thermal is straightforward, requiring only paper.

-- The "two color" ones use a ribbon and dot matrix.

-- joey's keyword of "ticket printer" might be the customer's preference, producing a light cardboard ticket as in a parking garage, rather than paper as POS receipt.

 

Need now to find out what end customer really wants.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know what he wants: cool, fast, rugged, cheap.

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Last time I worked with POS printers, you could go to epsonexpert.com and get the docs. It was just a PDF. They're pretty easy to work. You have to register, but that wasn't a problem. Most are USB these days but I think all our AVR's with USB built in are slaves not masters.

274,207,281-1 The largest known Mersenne Prime

In that awkward stage between preschool and death

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Six years ago I did a project for a Canadian Government department that involved the Epson TM-T88IV thermal printer commonly used in supermarket POS checkouts.

 

 

I used the RS232 interface option. Epson has a few documents that define the low level commands for eg defining the "page" size, font size, cutting the "ticket". Yell out if you go down this path and need the Epson docs.

 

Cheers,

 

Ross

 

Ross McKenzie ValuSoft Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft wrote:

Six years ago I did a project for a Canadian Government department that involved the Epson TM-T88IV thermal printer commonly used in supermarket POS checkouts.

 

 

I used the RS232 interface option. Epson has a few documents that define the low level commands for eg defining the "page" size, font size, cutting the "ticket". Yell out if you go down this path and need the Epson docs.

 

Cheers,

 

Ross

 

That's what I found when looking at a popular Citizen line also.

 

In a past life we used Brady and Zebra printers for industrial applications.  This Zebra "ticket" printer caught my eye https://www.zebra.com/us/en/prod... Not as inexpensive as Micronics or Epson or Citizen, but perhaps built for heavier duty?

Robust enough to quickly print high volumes of ATB1 boarding passes, bag passes, bag tags, and tickets, this kiosk printer offers RS232 serial interface only.

If it were me, I think I'd like the actual "ticket" as below, rather than a stack of flimsy paper "receipts".