How to connect printer with embedded system?
Michael Tien
I've used printer ESC/P sequence to control printer for customized
graphics and font a while ago. I could use most of the Epson and Canon
printer then. But now it seems most the cheap printer in the market do
support ESC/P or ESC/P2. Does anybody know how to do it right now? Thanks
in advance.
Michael
Michael Tien
support ESC/P or ESC/P2.
"Michael Tien" <mt...@magnetargames.com> wrote in message
news:ftf68.37597$M3.53...@news1.telusplanet.net...
Tauno Voipio
"Michael Tien" <mt...@magnetargames.com> wrote in message
news:ftf68.37597$M3.53...@news1.telusplanet.net...
Many of the cheap printers are Winprinters: the processing in the printer
has been moved to the driver software in Windows. The printer is just plain
trash without Windows - forget it.
Tauno Voipio
tauno voipio @ iki fi
Michael Tien
Thanks for reply. That is what i worry about that there isn't easy way
for printer control anymore. Since the printer also works for Linux, maybe
there still some source code available for winprinter.
Lewin A.R.W. Edwards
> support ESC/P or ESC/P2. Does anybody know how to do it right now?
Thanks
Simple test: Boot machine to raw DOS. Type "dir >lpt1", then "echo ^L
>lpt1". (^L = Ctrl-L). If you don't get a page of recognizable output then
it's going to be hard to use that printer with an embedded system.
--
--- Lewin A.R.W. Edwards
http://www.larwe.com/
Lewin A.R.W. Edwards
> has been moved to the driver software in Windows. The printer is just
plain
> trash without Windows - forget it.
How common is this with non-USB inkjet printers, I wonder? The printer has
to have a microcontroller in it. They usually have buffer RAM. The computer
isn't directly controlling the print head; at most it is rasterizing the
image. So it must be possible to control these devices from _fairly_
constrained systems.
Mark A. Odell
news:v6h68.7665$0V6....@nwrddc02.gnilink.net:
Sure it is. HP printers speak PCL. You can send PCL commands to the printer
and it will print them. I suppose you need ether to send a complete page
fast enough to keep up with the printer buffer drain rate or find out if the
printer can buffer an entire one of your pages before saying "form feed".
--
- Mark A. Odell
- Embedded Firmware Design, Inc.
- http://www.embeddedfw.com
Lewin A.R.W. Edwards
printer
> and it will print them. I suppose you need ether to send a complete page
> fast enough to keep up with the printer buffer drain rate or find out if
the
> printer can buffer an entire one of your pages before saying "form feed".
Ermmmm... or just obey the flow control protocol for the interface being
used! :)
Mark A. Odell
>> Sure it is. HP printers speak PCL. You can send PCL commands to the
> printer
>> and it will print them. I suppose you need ether to send a complete page
>> fast enough to keep up with the printer buffer drain rate or find out if
> the
>> printer can buffer an entire one of your pages before saying "form feed".
>
> Ermmmm... or just obey the flow control protocol for the interface being
> used! :)
Aha! Yes, that'd do it. :-)
Michael Tien
support pcl. Look like that's my only brand that I can choose.
http://products.hp-at-home.com/products/detail.php?id=C6467A&display_specs=f
ull_spec&j=1
Frank Bemelman
Michael Tien <mt...@magnetargames.com> schreef in berichtnieuws
KLi68.22883$_F4.4...@news0.telusplanet.net...
> Just search the HP website for a cheap printer Hp deskjet 630c. It also
> support pcl. Look like that's my only brand that I can choose.
Make me wonder if there are small converters available that translate
good old epson > PCL.
--
Thanks,
Frank Bemelman
(remove 'x' when sending email)
Alan Gosselin
Most "cheap" HP printers no longer speak PCL. As someone
else said, the processing has moved into the computer. There
was an article in the long-lamented "HP Journal" about 5
years ago.
Printer processors were being forced to get faster at about
the same rate as PC processors. Users wanted faster printing
with more resolution. PCL allowed the computer, for
instance, to send a simple command that said, in essence,
draw a single line from the upper left to the lower right of
the page. The printer would have to rasterize that, and
probably save it away in memory, so that it could put down
toner at the correct time.
All of the rasterization has been moved into the PC, so what
come out now is little more the than actual dotss to put on
the page. The printer processor controls the buffering of
the data, the movement of the print head and the spitting of
the dots.
That's one way you get printers that cost under $50, even
assuming HP, et al, want to make their money on the
supplies, and the printer is a loss leader.
CBFalconer
>
... snip ...
>
> All of the rasterization has been moved into the PC, so what
> come out now is little more the than actual dotss to put on
> the page. The printer processor controls the buffering of
> the data, the movement of the print head and the spitting of
> the dots.
>
> That's one way you get printers that cost under $50, even
> assuming HP, et al, want to make their money on the
> supplies, and the printer is a loss leader.
I can put up with that, which is no worse than having to prepare
graphic images for an Epson RX80 line by line. What I object to
is lack of an interface specification. I want to know what to
send the beast to make it do things, how to interrogate it, etc.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
William Meyer
news:3C5A01E6...@yahoo.com...
>
> I can put up with that, which is no worse than having to prepare
> graphic images for an Epson RX80 line by line. What I object to
> is lack of an interface specification. I want to know what to
> send the beast to make it do things, how to interrogate it, etc.
Chuck, you're showing your age: we remember when documents were thorough,
and printed. <g>
Bill
Meindert Sprang
news:a3cen3$30al$1...@scavenger.euro.net...
>
> Michael Tien <mt...@magnetargames.com> schreef in berichtnieuws
> KLi68.22883$_F4.4...@news0.telusplanet.net...
> > Just search the HP website for a cheap printer Hp deskjet 630c. It also
> > support pcl. Look like that's my only brand that I can choose.
>
> Make me wonder if there are small converters available that translate
> good old epson > PCL.
>
PCL is very straightforward, especially up to PCL3. It works like the old
Epson protocol. Send a few escape sequences to set the printer in raster
mode and send a raster lines. When the page is complete, another escape
sequence starts the actual printing on laserjets. The biggest difference
with Epson and PCL is that with Epson, the raster data is one byte for 8
vertical pixels and PCL is one byte per 8 horizontal pixels. So effectively,
with Epson, you wrote one raster band consting of 8 image lines and with PCL
you write only one line. Laserjets used to buffer an entire page, deskjets
usually buffer a small portion, with a size the printerhead can print at
once.
Meindert
Matt Boothe
PostScript are classified as "business" inkjet printers and certainly cannot
be classified as cheap.
These printers have an onboard RIP (Raster Image Processor) which these days
is a 32-bit computer with a bunch of DRAM. All printers (laser, business
inkjet, personal inkjet) have a microcontroller based "engine" which handles
the low level motor control etc.
RIPs are very expensive which is why you won't find them in a personal
inkjet printer. For example, the RIP for the Lexmark C750 (a color laser
printer) uses a QED 32-bit processor running hundreds of MHz and embedded
Linux. That RIP includes at least 64 MB of DRAM. I'm not as familiar with
inket RIPs but since they do the same job as laser RIPs I imagine they are
very similar.
Anyway, if you want a simple PCL interface to an inkjet printer and you're
willing to spend the bucks, check out the Lexmark Optra Color 40, Lexmark
Optra Color 45, or Lexmark J110. I'm sure that HP and Epson have business
inkjets too, but I don't know the model numbers.
Matt
"Alan Gosselin" <algoss.ta...@portone.com> wrote in message
news:3C59DDB2...@portone.com...
Lewin A.R.W. Edwards
days
> is a 32-bit computer with a bunch of DRAM. All printers (laser, business
To pick one example out of millions: DeskWriter 630. 8-bit microcontroller
IIRC. Certainly no embedded Linux. PCL isn't a computationally intensive
language (PostScript is).
HIGH-END printers with PostScript support are expensive, sure. But they are
typically built for massive document-processing speed, have levers and knobs
and buttons for sheet-feeders, book-binders, multiple gigabit Ethernet
interfaces, Internet-based administration functions, partridges included
(pear tree available at additional cost).
Meindert Sprang
news:5Hx68.8074$pb....@nwrddc01.gnilink.net...
> > These printers have an onboard RIP (Raster Image Processor) which these
> days
> > is a 32-bit computer with a bunch of DRAM. All printers (laser,
business
>
> To pick one example out of millions: DeskWriter 630. 8-bit microcontroller
> IIRC. Certainly no embedded Linux. PCL isn't a computationally intensive
> language (PostScript is).
>
Not quite expensive RIP's I would think. The both speak PCL
Meindert
Lewin A.R.W. Edwards
> Not quite expensive RIP's I would think. The both speak PCL
Yes, and a lot (a LOT a lot) of laser printers were built around the
MC68008. The odds of finding a 68008 under the hood of a laser printer in
the early 90s were better than 75% :)
Robin Soper
format documents so a printer will understand them or how to control
the printer at a low level, or both.
For formatting perhaps you could use postscript which most decent
printers understand - maybe make use of GNU ghostscript to process
your docs before sending to printer.
Hope this helps
Regards
Robin
"Lewin A.R.W. Edwards" <la...@larwe.com> wrote in message news:<F5h68.7664$0V6....@nwrddc02.gnilink.net>...
Michael Tien
easy to convert my old code (ESC/P sequence) to PCL.
Michael
"Meindert Sprang" <mhsp...@customware.nl> wrote in message
news:3c5a8850$1...@news.nb.nu...
Lewin A.R.W. Edwards
news:e3bb9f9f.02020...@posting.google.com...
> I not sure I fully understand whats being asked here - is it how to
> format documents so a printer will understand them or how to control
> the printer at a low level, or both.
Kind of both. We were discussing whether or not modern printers support
documented, fairly popular languages such as PCL and EscP (Epson's old dot
matrix language). Some modern printers are GDI printers, which means the
rasterizer (font and graphic object rendering) is done in the (Windows)
driver. The printer has a microcontroller and motor control/head control
electronics in it, but the comms protocol is proprietary and totally
undocumented, making it hard to interface such printers to embedded systems.
A simple test for a GDI printer is to try printing from raw DOS.
Matt Boothe
available on the RIP's of current products. This is true on the $3000
Lexmark C750 as well as the $400 Brother HL-1650. Certainly every RIP
doesn't embed Linux, but I'd be surprised if there were any modern RIP's
running on a 16-bit micrcontroller.
The odds of finding two microcomputers (and engine and a RIP) under the hood
of a modern business printer must be greater than 90%. The engine processor
will be pretty low end, but my guess is that most RIP's are 32-bit.
Matt
"Lewin A.R.W. Edwards" <la...@larwe.com> wrote in message
news:Tey68.8101$pb....@nwrddc01.gnilink.net...
Michael Tien
their web site. And HP printer still talk PCL. But for the Canon printer
(and are our previous choices) I can't find anything in their site. And
just forget about USB printer.
"Peter" <z...@ds1.com> wrote in message
news:qc9o5u050iil81n2j...@4ax.com...
>
> The Epson parallel-port printers I have played with in the last 1-2
> years all support ESC/P2.
>
> Most lasers still do a HP Laserjer-something emulation.
>
> There was an era, some years ago, when "windows printers" were
> popular; the PC did the rasterising. But from what I can see, the
> industry has retreated from that. Not least because if the user
> changed his O/S, the printer manufacturer came under huge pressure to
> supply a new driver, otherwise the printer became completely useless.
>
> The problem now is USB-only printers. Like USB-only scanners. No cheap
> way to talk to those, in fact it is very complicated indeed because
> you have to make a USB controller.
>
>
> Peter.
Rakko
> Some modern printers are GDI printers, which means the
> rasterizer (font and graphic object rendering) is done in the (Windows)
> driver. The printer has a microcontroller and motor control/head control
> electronics in it, but the comms protocol is proprietary and totally
> undocumented, making it hard to interface such printers to embedded
> systems.
Hi, all! I just happened upon this group because I'm looking for information
on microcontrollers used in printers and the protocols they use. Well
actually, I'm looking for information on the Lexmark Z23 and Z33 printers,
but I was hoping I could find someone who knew enough about the issue in
general to help me. Here's some background:
1. I'm trying to figure the driver out because in Linux (using
Lexmark-supplied closed-source drivers) output is *almost* satisfactory,
but not quite (everything is moved about .5" up from where it should be, so
some text goes off the top of the page).
2. I've 'printed' a few test files to a file, in order to capture the
control codes generated.
3. All the files I generated in this way share a lot of stuff at the
beginning and end. Most interestingly, they all have near the end a bunch
of strings, to wit:
Divide by zero
ABEX
Return code too large
No Stack for Trap Handler
Recursive Trap
Unknown Error
Branch Through Zero
Undefined Instruction
Undefined SWI Instruction
Prefetch Abort
Data Abort
Address Exception
Unhandled Interrupt
Unhandled Fast Interrupt
Stack overflow
Abnormal termination (e.g. abort() function)
Illegal instruction (call to non-function/code corrupted)
[is the floating point emulator installed?]
Interrupt received from user - program terminated
Illegal address (e.g. wildly outside array bounds)
Termination request received
User-defined signal
Stack overflow
The second one, "This code can only run on a Thumb compatible processor," is
what got me thinking about embedded systems. Now, I have absolutely no
background in embedded anything, but my current hypothesis is that *maybe*
some of the code the printer sends is actually Thumb machine code. Just so
I can find out if I'm off-base or not, does anyone here know if GDI
printers work that way, i.e. do some of them actually send *machine code*
to the printer? I'd appreciate any wisdom anyone could share, even if it's
general, but knowledge of Lexmarks would help even more.
Thanks in advance!
John Eaton
: The second one, "This code can only run on a Thumb compatible processor," is
: what got me thinking about embedded systems. Now, I have absolutely no
: background in embedded anything, but my current hypothesis is that *maybe*
: some of the code the printer sends is actually Thumb machine code. Just so
: I can find out if I'm off-base or not, does anyone here know if GDI
: printers work that way, i.e. do some of them actually send *machine code*
: to the printer? I'd appreciate any wisdom anyone could share, even if it's
: general, but knowledge of Lexmarks would help even more.
That's what it's doing. The printer is downloading its code and printdata
into ram and then running. The advantages are that you can build your
printers with a very small (probably serial) boot rom with robust code
and a very small chance of ever needing upgrading. If you find a bug you can
fix it via a driver turn.
It does slow things down while the code is loading and you need enough
security so that someone doesn't dump the code, modify it and then
send it to the printer but when price is the only concern it is the
way to go.
John Eaton
Rakko
> Rakko (ra...@panther.kittyfox.net) wrote:
>
>
> : The second one, "This code can only run on a Thumb compatible
> : processor," is what got me thinking about embedded systems. Now, I have
> : absolutely no background in embedded anything, but my current hypothesis
> : is that *maybe* some of the code the printer sends is actually Thumb
> : machine code. Just so I can find out if I'm off-base or not, does anyone
> : here know if GDI printers work that way, i.e. do some of them actually
> : send *machine code* to the printer? I'd appreciate any wisdom anyone
> : could share, even if it's general, but knowledge of Lexmarks would help
> : even more.
>
> That's what it's doing. The printer is downloading its code and printdata
> into ram and then running. The advantages are that you can build your
> printers with a very small (probably serial) boot rom with robust code
> and a very small chance of ever needing upgrading. If you find a bug you
> can fix it via a driver turn.
[...]
Hi, John! Thank you for the information. I have some further questions, if
you (or anyone else who wishes to jump in) don't mind:
Do you know of any specific printers that operate like that (and which
ones)? Any links to info on them?
What do you mean by "serial" boot ROM?
Can you tell me anything about how I might be able to find out what part of
this code is executable, what part is "wrapper" (if any), etc.?
Thanks again!
John Eaton
: Do you know of any specific printers that operate like that (and which
: ones)? Any links to info on them?
Hard to say. If it's windows only and cheap then you can do anything you
want between the printer and driver. If it support postscript or PCL from
any host then it's probably not.
: What do you mean by "serial" boot ROM?
Roms that support serial protocols such as i2c or spi. Super cheap,
slow and usually in a 8 pin package. Rom is loading into dram for
execution and can download other code via the I/O
: Can you tell me anything about how I might be able to find out what part of
: this code is executable, what part is "wrapper" (if any), etc.?
If you can recongize the opcodes then go in with a dissassembler and see what
looks normal. These interfaces are never documented outside the company because
nobody wants to support customer written code.
John Eaton