Hi,
Like Brooke, I’m interested in developing an Epson inkjet driver for experimental chemical synthesis. Is anyone else currently working on this, or is anyone interested in working on it with me? If this doesn’t interest, you then please feel free to stop reading now. I have no desire to be responsible for anyone’s death due to this boringly long-winded and tediously detailed post.
I’ve been attempting to get a separated drop output using Gimp, gimp-print, and an Epson Photo 960 as follows:
In gimp I created a 12 pixel by 12 pixel block at a resolution of 1440X1440dpi. In this block I then colored pixels 00, 60, 06, and 66 black (00 is the 0 x-coordinate, 0 y-coordinate pixel in the top left corner of the block). I then saved this as a “fill” pattern in gimp (0060.pat). This separation may seem excessive; however I’ve calculated that a “spherical” 2 picolitre drop of water should have a diameter of about 15.6 microns while at 1440 dpi an individual pixel should be about 17.6 microns across. If I assume that the 2pL drop becomes hemispherical when it sits on a non-wetable surface (I‘ve been using transparencies), then that hemispherical drop would be about 19.7μm in diameter. In practice the smallest droplets I’ve observed under a microscope have been 30μm in diameter and the majority I’ve seen have been about 40μm in diameter, so each drop occupies about 2 pixels and my fill pattern should print a separation of 3 blank pixels between filled ones.
As Mr. Krawitz pointed out in his first comment, what I created was a pre-dithered input. I used my pattern to fill a 1 inch wide by ½ inch tall rectangle in Gimp and printed it many times using different combinations of gimp-print parameters. I got closest to the separation I’d hoped for using 1440x1440 highest quality, 1440dpi magnification, colored output, and very fast dithering (I know there were some other parameters too but I can’t think of them right now). Near the center of the 1 by ½ inch block thus produced I got a nice grid of 40μm drops separated both vertically and horizontally by about 40μm. However, for about the first 40 rows from the top I got the following pattern. First, three rows of 40μm drops separated both vertically and horizontally by about 40μm as above. Then a row consisting of pairs of small 30µm drops 5µm from larger 40µm drops with about 40μm of horizontal spacing between each set of pairs. Further, the last third of the rows in the printed figure consisted almost entirely rows of this paired dot pattern.
At this point I became curious as to what the gimp-print driver was actually telling the printer to do. So I saved a hex dump of the driver output to file, and began parsing it by hand using Epson’s ESCP2 manual, the programming manual for the photo 960, your ESCP2 info, and anything else I could find on the subject. I now understand some of the remote mode commands (more than a few still appear undocumented), most of the ESCP2 commands (a few confuse me, perhaps we can discuss this later), but I’m rather lost when it comes to the actual data encoding. For instance, I would have expected my pattern of one dot every 6 spaces to be encoded as 82 08 20 (1000/0010/0000/1000/0010/0000), but what I get is 92 49 24 (1001/0010/0100/1001/0010/0100). Is this due to dithering? Or is it that I don’t yet understand weaving? (I’m working on understanding both) Also, the count byte for each row calls for (hex) 57 or (dec) 87+1=88, 16 bit bytes, but a one inch row at 1440dpi would require 90*16 =1440 bytes. I do note that after the 88th byte the final 2 bytes do appear, although they are separated by 00’s (ie 92 00 49 00 24). I hope someone can give me a better grasp of the data encoding. It may seem odd to you that I looked at the hex output rather than your source code as a starting point here. In my defense, I can only say that I’m a chemical engineer who’s done a good bit of work in instrumentation and control. So I’m a lot more comfortable with the assembly language of ESCP2 than I am with the higher level (C code?) of your drivers. It was only at the point where I saw how different the output data was from what I had expected that I began to recognize how much the drivers were massaging the input. I entered this project imagining that I might control the printer like an old 9-pin dot matrix printer. You know: move the head x move, the platen y, fire pins 1,5,7, etc. Oh boy! Was I wrong.
At any rate, the pre-dithered input problem appears to be of concern to me and several others here:
From: Andrew A. Gill <superluser@xxxxx>
Darn you, stochastic dithering! I shall be avenged!
2004-07-20 21:38
|
Jernot Judman
(support requests)
Linux printing 16
bit pictures
2003-05-11
|
I suspect that the replies to these posts hold some of the information needed to enable pre-dithered input. As must be fatiguing obvious by now, I’m pretty highly motivated to work on this project. I see a lot of potential for many types of micron-scale manufacturing here. Sort of like rapid prototyping that produces by deign not a model of something, but the useable thing itself.
Concerning Mr. Krawitz’s second and fourth points, to me they appear somewhat related. I’ve tried taking one of my 1 by 2 inch printed blocks and re-feeding it through the printer for a second (over) print. I found very little displacement in drops between the first and second prints. For the most part, at least in the area where I had the desired separation, the second coat of drops appeared to be right on top of the first. I think this is referred to as very good registration. However, I haven’t examined if the printer is capable of placing one colored drop directly on top of another during a single file printing cycle. This might be useful, but I don’t think it’s essential for what I have in mind. What I’ve been thinking of is a print file consisting of the initial remote and ESCP2 commands followed by the data for my pattern. Then, rather than ejecting the page, the file would instruct the printer to reverse feed to the position at which it had started printing the pattern. Following the reverse feed the file would contain the data to reprint the pattern (or print another pattern) which would be followed by another reverse feed, and so on. I understand that Epson has eliminated the ESC j code for reverse feeding, however I found a reference (I think in one of the Epson manuals) to a set of paper feed values that allow for up to ½ inch of reverse feed. (I guess I’m going to have to find that reference and make sure it works. I seem to remember it had to do with a number exceeding a certain value being interpreted as negative. It made sense when I read it anyway). You can see now why I’ve been working with a block ½ inch high.
Another possibility for reverse feeding may dovetail with the work people here have been doing on CD printing. I’ve been hoping to use something like the CD holder (or even the holder itself) as a carrier for whatever material I use as a print substrate. I’ve noticed that, once the tray has been properly positioned, the first action of the printing cycle is to reverse feed (suck) the tray in by ½ an inch. If a figure ½ inch high were then printed, then the tray would return to its initial hand fed position. This would allow another file of a ½ inch high figure to be printed, and so on. I think the printer indexes this initial movement using the paper-out switch, which is a lever arm interrupting an optical sensor arrangement. There’s a slot cut in the CD tray, and when the tray is hand positioned the lever arm above the paper path drops into this slot (normally an out-of-paper or no-paper-loaded signal). I believe that the printer reverse feeds the tray until the arm hits the top end of the slot lifting it above the carrier (a paper-loaded signal) where it then stops. The distance of the reverse feed is the ½ inch needed to position the topmost point on a CD to be printed above the highest jet on the print head, and using the switch to do the positioning is likely much more accurate than any human operator. The feed CD tray behavior is quite different from the normal paper feed. Perhaps the instructions for this feed are part of the undocumented remote commands. Conceivably, the remote command might also point to a hard “EEPROM” coded feed sequence.
I sincerely apologize for the great length of this post. I’ll try to keep it short in the future. I didn’t intend to write a novel here. I did however want you to have some idea of what I’ve done so far, what I think a driver for this purpose might need to do, and how I think such a driver might accomplish these ends. Please let me know of your ideas. Many, if not all, of you understand what must be done here much better than I do. I would sincerely appreciate your advice and assistance. Also, if there’s anything I can clarify please let me know. Perhaps as a starting point, we might outline the work needed to produce a non-dithering driver. I look forward to hearing from anyone interested in this project. Here’s a final thought: Given that almost every computer in the world has some sort of hard copy output device, isn’t it surprising how little information is available concerning their operation. Thank God for Linux and the Linux community.
Your friend and I hope colleague,
Wayne Brooke-Devlin
By: brookepb ( Brooke )
Getting started writing customized drivers
2004-02-17 08:00
Hello,
I apologize for this being off-topic but tried to hit the open
discussion forum as the least offensive and I don"t know where else I
might find information to get started.
I am hoping that someone can point me toward more appropriate resources
for learning what I need to know to write custom minimal printer
drivers. My intention is to use an inkjet as an experimental chemical
synthesis platform for my research but find that while many people have
done so, they all seem to have jumped into making a company to exploit
their work and thus aren"t terribly forthcoming about methods and
techniques or they simply haven"t responded to my requests for "how"d
you do it?".
Unlike regular printing applications, I prefer my dots to be separated.
:o) I was hoping to be able to buy a five or six color printer with
variable drop size control and reverse line feed control. My custom
driver would just be able to let me say which cartridge (w/ the ink
replaced by my chemical of choice) would contribute to which location
and ideally the relative volume of the chemical deposited there. I would
need to be able to revisit the same spot location multiple times so I
can react the different desired chemical combinations at that location.
This is just basic combinatorial chemistry but using an affordable (the
big driver here :o) and reliable chemical dispenser for my own research.
This would of course critically depend on being able to return to the
precise location of a previous dot with close to no spread(spray) of
droplet fragments while in flight.
Any pointers to information about the appropriat forum for questions
like this, writing custom printer drivers and/or what off-the-shelf
common printers might fit the bill would be welcome.
Thanks,
Brooke
-=-=-=
By: rlk ( Robert Krawitz )
RE: Getting started writing customized driver
2004-02-17 17:33
This is actually reasonably on-topic, although it"s easier to
discuss on the gimp-print-devel mailing list, which you"re welcome to
subscribe to.
We don"t try to keep our stuff secret, obviously :-) This is a
rather interesting application. Gimp-Print as is won"t quite do what you
want, although a couple of weeks of work could probably make it fit the
bill. There are a few issues I can see:
1) Gimp-Print doesn"t support pre-dithered input; you can give it
8 or 16 bits, but it dithers it down to the 1 or 2 bits that the
printers actually support. Adding this facility would be useful, but
it"s not at the top of my agenda. If you want to do it, though, it
likely wouldn"t be too hard to do. There"s also a way to work around
this with the 16-bit input; if you decide to proceed with this project,
we can discuss that.
2) Gimp-Print also doesn"t support overprinting in this way.
Again, this is a simple matter of software. It"s less interesting to me,
since it doesn"t have a lot of application for general purpose printing,
but it could be done if you wanted to without too much difficulty.
3) All of the printers that support variable drop size support
only 2 or 3 drop sizes at a given resolution, with fixed ratios. At
least, I"m not aware of any Epson printers that allow programming the
drop sizes in arbitrary ratios, and if there are, I don"t know how to
program them.
4) I"m not aware of any cheap inkjets that allow reversing the
feed (I"m not aware of any expensive ones that do, either, but that"s
neither here nor there). If there are, that"s also something that would
need to be reprogrammed in Gimp-Print, but that"s also a simple matter
of programming. The hard thing is finding the printer meeting your
specs.
5) Inkjets print in bands, and the printing pattern isn"t very
simple. They don"t simply print one row of dots and move to the next.
You could easily hack Gimp-Print to do that, though, but it would make
for very slow printing.
Gimp-Print 5.0 alpha supports a mode whereby you can control each
color independently (the "raw" mode). That would be ideal for your
purposes.
