Inkjets anyone?

[sixtharmy]

Hi, I'm new to the forum and fairly new to CNC. I hope no one minds me starting right off in a new thread, but though inkjets are mentioned in a number of other threads here, in each case their inclusion always seems to be peripheral to something else. I'm really only interested in a CNC/inkjet type machine. I don't care if you want to fill it with a polymer binder for rapid prototyping work. I don't care if you want to fill it with conductive ink for PCB work. I don't care if you actually want to fill it with ink to print on some other substrate than paper like cloth or vinyl. I don't even care if you want to fill it with urine , but I don't think I'd want to know why. Nevertheless, I'd be happy to discuss these things as it applies to getting an inkjet to do them (maybe not the urine). However, it seems to me to be necessary to first come up with some hardware/software before discussing how we'll apply it.

Most of my comments here are going to concern Epson printers, but from what I've seen they also apply to Cannon, HP, etc. to a slightly greater or lesser degree. I've been noodling around with Epson inkjet printers for about a year now trying to get them to do things not envisioned by their designers. I've concluded that its quite difficult. As a simple example, most newer printers do not have a reverse feed command in their higher level "programming" languages. Why should they? They're designed to suck in one piece of paper print all the way down it and spit it out. No reverse feed is needed. I started looking at these machines as if they were old dot matrix printers or early plotters. Those machines you could program directly. (ie move x, move y, fire pin one, etc.) This is no longer the case.

Much of the problem stems from the hardware/firmware of the printer controller board. Generally the firmware is written in an undocumented assembly language to run on a custom and undocumented processor by way of a custom and undocumented ASIC. The higer level language with which you program the printer merely supplies data to subroutines in the firmware, and error conditions result from supplying that data in any other form or order than that in which the subroutines require it. In addition, as the printer executes its functions it must see certain sensors change state. A power on routine generally consists of: Move head to right until head position home sensor responds. Move left x spaces to wipe the head. Move right to position head over jet primer. Run the motors/head to prime head. Move left x spaces to push on paper feed gear cam. Run paper feed motor until paper feed sensor responds. If the paper error sensor also responds, then advance the paper y units to the top of form. If any sensor does not resond, or resonds in the wrong order, then cease all operations except for blinking a red error diode at the swearing operator. This is a simple example for the sake of brevity.

However, all is not lost. It seems to be possible to eliminate the contoller board entirely and to run the positioing motors (duh!) and print head directly. Google the word "POSAM inkjet" and read a bit about their hardware/software. Considering the level of technical knowledge available here, I think we could come up with something much cheaper and probably easier. Think on it. I've written too long already. I'll do more tomorrow.

[greybeard]

Hi sixtharmy. I, too, am still in the newbie catagory, but I have started building.
My first thoughts when I found the forum were "at last I have an excuse to recycle the 1500 and the 1520", but soon moved on, and have since aquired more background from all the postings here, and some of the hardware to go with it.

On the topic of the software for epsons - my machines have a "micro feed adjust" for lining up the paper before printing, which give a limited movement in both directions. I know nothing about programming, but are there any possibilities there ?

Looking forward to your next instalments,
John

[xaq]

You might check out:
http://www.parallax.com/detail.asp?product_id=27949

It let's control an HP inkjet cartridge over a serial port. It's a bit limited at 96dpi, but it's a simple place to start...

Zach

[sixtharmy]

OK, if you looked at the POSAM "User Manual Chapter 1: Assembly" and skipped everything about oligonucleotides etc., then you would have seen that these guys used only the print head of an Epson Stylus Photo 700 printer. They drove this head using mostly handmade boards (PCB file and parts list supplied), and software (source code supplied). This is about the only part of the design (excluding cameras) that should be unfamiliar to people on this forum. The rest is ball screw positioners, servos, controllers, and the like.

I think, however, that their software design is far too specific to their application. It would be very difficult to make POGO, Lombardi, or Arrayer produce anything but sequences of oligonucleotides. In addition, I think that their hardware solution is far too expensive. I certainly don't want to drop a grand on a National Instruments GBIB board. You guys have been inexpensively interfacing devices to PCs for years. Can you think of better way?

Another concern I have is that the software/hardware design is far too specific to the Epson Stylus Photo 700 head. This printer was introduced early in 1998. After almost eight years these printers are getting thin on the ground, even on ebay. As far as I can tell from service manuals and schematics, the method of driving a print head as described in the POSAM documentation has not changed. A serial signal sequentially latches each piezo/jet in a column (color) either on or off. When the latch buffer(s) are full a DAC produces an analog wave form that pulses those piezos latched "on" shooting out a drop of ink from their jets. (Incidentally, for anyone interested in thermal inkjets, I believe they use the same system except the pulse runs the heating elements.) Though this method hasn't changed, the hardware it runs has improved quite a bit in eight years. Epson’s current top line photo printer the R800 dispenses 1.5 picolitre droplets (SP700 6-10pL) of 8 different colors (SP700 6 color) from 1440 nozzles (SP700 192 nozzles). Nor has inkjet technology reached its limits. Fempto (10 to the minus 15) litre drops are possible. I think it may be worthwhile in any design we develop to allow for variations to be made in software/hardware to accommodate different print heads.

I've probably written too much already, but let me comment briefly on scale. A 1.5pL hemispherical droplet sitting on a surface would have a circular footprint about 18 microns in diameter. You'd have to line up 4 such droplets before they'd become visible to the naked eye. You could line up over 1400 in the space of an inch. How many technologies can you think of that allow you to pattern/build anything at that scale? Wouldn't it be nice to have another that can maybe do things the available technologies cannot? There's a great deal of corporate and academic research being done. I doubt industry will make the resulting tech any more available to us than they currently make available printer tech. Till tomorrow.

[greybeard]

Hi sixtharmy. Having just read your latest, I can see that I missed the direction of your initial posting. I now realise it's the control of the placement of the contents of the inkjet head that is your main interest, rather than hardware. Please correct me now if I'm wrong, as I'll go off at a tangent at the slightest nudge of a grey cell.

A thought for those reading, and thinking what else could you put through the printer head. The chemistry that is used to produce silver mirrors should allow you to deposit silver (or copper) patterns onto a heated surface instantly. A saturated alkaline solution of ammonical silver nitrate correctly made up will reduce to silver on hitting a hot surface.
This is how paper can be coated with silver in fanmaking - I've done it, and onto mother of pearl.

So, as I've suggested in another thread somewhere, you could produce your pcb's directly.

[sixtharmy]

Hi Greybeard, Let me take your comments more or less in order.

I'm afraid that the microfeed buttons available on the vintage 1996 Stylus Color 1520 aren't of much help with what I'm considering. I'd like to bypass Epson's built in controller/firmware through which they operate. In addition, as far as I can remember, the SC1520 was one of a very few of the more than 70 inkjet models that Epson has produced since 1992 that implemented this feature. I believe it was because the SC1520, unlike most Epson inkjets, had a tractor feed for fan fold continuous paper like older dot matrix printers. There's a fair amount of slop in this feed system and the manual microadjust was to allow you to move the paper back and forth a within a quarter inch or so to hand "register" the top of the first form beneath the print head. Great idea though. I remember standing in a second hand store about a year ago staring at an SC1520 and thinking the same sort of thing.

As to your second comment, I'm interested in coming up with a hardware/firmware/software solution that will replace the print head (x) paper (y) and jet firing (z or some other axis like router speed) contoller within a printer. This would allow us to remove just the print head (the part that moves back and forth on a rail) from a printer and mount it on the sort of (x,y,z) positioning equipment used in CNC so that the head can be used to do things that it can't do while trapped in the hardware/firmware that's only meant to print ink on paper.

As to your third comment, I can go at least one better. Several manufacturers (Xerox, 3M, etc.) have conductive inks available that should be compatable with inkjets and you can bet that they're working on inks that are definitely compatable. So it is reasonable to expect that you could pattern a PCB in a CAD program and print the traces directly to a CNC predrilled resin board with no heat or wet chemistry. Further, I've seen some reports of resistive inks. So instead of computer positioning and wave soldering a passive surface mount resistor between the conductive traces you've printed you could concievably print a drop of resistor between those traces, as you're printing the traces. I've even read a few papers in which semiconductive and insulating inks have been layered to produce active components. In the last six months or so you may have seen in the news prototypes from Epson, Sharp and others of paper thin, flexible display screens. Guess how the Organic Light Emitting Diodes that make this tech possible are put on the flexible polymer sheets? Yup, inkjets.

[sixtharmy]

Hi Xaq, Great little site. I hadn't seen this before. I'm not terribly interested in HP inkjets (for a number of reasons that I'll probably get into sometime), but there is so much overlap among different designs that I'm sure I'll discover something interesting. Thanks again.

I read a while back that a digruntled ex-employee, or engineer, or designer, or consultant for HP revealed that they used an uncommon, but available, assembly language in the firmware of their printers. As a result it is possible, though far from easy, to reprogram their firmware. I suspect that this is true, because about 6 months ago some people at Clemson who are using HP inkjets to produce artificial bio membranes reported in a paper that they were using HP printers with altered firmware. This may be a way to approach the inkjet control problem. We'll have to see.

This brings up another point. Manufacturers go to great lenghts to keep other manufacturers (and us) from finding new ways to use their equipment from which they can't earn a buck. They all use the Gillette marketing strategy of "give them the razor , but sell them the blades" in terms of printers and ink. So, they engineer in all sorts of ways to keep you buying only their ink. If you don't even use ink, then they earn nothing. In fact, they sell the printers so cheaply that they might actually lose money.

To give an example of how far they go to protect their technology consider the following. The Epson Stylus Color 740, Stylus Photo 750 and Stylus Photo 1200 all use the same controller board, though presumably with slightly different firmware. This board comes in a Rev. A (used briefly) and a Rev. B form. In the Rev. A the bipolar stepper motor used to advance the paper is controlled by a pair of 16 pin Allegro 3955 chips. In the Rev. B the same function is preformed by a pair of 24 pin Allegro 3957 chips. Allegro publishes a great deal of information about the 3955 (good site about stepper control!). They don't even list the 3957. As far as I've been able to determine, the 3957 is a 3955 with eight extra legs that electonically do absolutely nothing. In fact, I doubt that they're even connected to the IC's microcircuitry. They do, however, alter the order of the functional pins from the pin-outs of a 3955. As a result, it's necessary to take a scope to the operating chip to find out what's what. Epson payed Allegro to manufacture their 3955 silicon in a slightly different plastic package just to make reverse engineering their controllers a tiny bit more difficult. This is only one of the booby traps I've discovered while examining their hardware. Its another reason that I suggest building a controller from scratch, rather than trying to use anything but the absolute minimum of manufacturer hardware. If I have so more time I'll bore you all again later today. If not tomorrow.

[abasir]

sixtharmy,

Let me throw in my 2-cents
I'm still not sure what you intend to do but it appears that:
1. You've been able to figure out how to drive the Epson printhead directly (POSAM...)
2. You're very familiar with programming.

That being the case, why not just attach the Epson printhead to a normal XY(Z) CNC machine and just write the software to control the movement and trigger the printhead. Most CNC are step/dir driven so it's easy to locate the printhead to where you want it to be. If you're electronically inclined, may be make a simple PIC/AVR controller to 'translate' Z-axis movement into printhead firing sequence thus allowing you to use the off-the-shelf G-Code translators in the market (Mach2, TurboCNC, etc).

I'm keen to get this going but the epson printhead mentioned is too pricey for my butcher knife What are the disadvantage/limitation of other (cheaper) printheads?

[sixtharmy]

Hi Abasir. You've got a pretty good idea about what I'd like to do. I want to pull the head from an Epson inkjet and mount it on a CNC machine to draw in ways and with things that have never been used in printers. The difficulty isn't with moving the table around. The difficulty is with running the inkjet and coordinating it with the table. I think that its going to be far more difficult than just "translating" the Z-axis control.

The first thing you must realize is that a file you save from a CAD program has the same relation to the same file printed on paper as a fertilized egg has to a chicken. Sure all the information to make a chicken is there, but it sure don't look anything like a chicken. Transforming a file to print is a pretty complex process. It used to be done almost completely in the printer. Here's an article describing the hardware/firmware of an HP printer circa 1992.

http://www.findarticles.com/p/articl...43/ai_13073623

In the late 90's about two thirds of this processing was moved to the printer driver. Here's an article article describing what is now in driver software.

http://www.findarticles.com/p/articl...48/ai_19540804

So building a print engine in hardware/firmware becomes easier, but its still not simple. Here are two articles one about the hardware and firmware that is still needed in the printer even after moving lots of functions into the driver that runs in the host computer.

http://www.findarticles.com/p/articl...48/ai_19540806
http://www.findarticles.com/p/articl...48/ai_19540806

It seems that this might be implemented in a pic type contoller, or perhaps completely emulated in software, or some buyable dedicated device. However, I'm really not very familiar with programming or hardware. I've just spent a good deal of time finding and absorbing very hard to obtain and obtuse information about printer operation. I'm open to all suggestions.

Oh, by the way, the only limitations to older heads is that their resolution won't be as high and they won't deposit material as quickly as the newer heads. When I mentioned that our design should allow for variations in hardware/software I meant that we should allow for both older and newer heads. Old ones you can get just about for free, but every head type requires slightly different circuitry and software control. More tomorrow

[abasir]

sixtharmy,

I'm assuming a new application will be written to support what you want to do. If you intend to use existing software and yet drive your cnc/diy-printer, it's gonna be a tough call.

My original idea is to write an application that will output required motion in modified G-Codes, i.e., XY motion in G-Codes but printhead controls are somehow encoded the Z axis. I will then have the XY motion be translated by the CNC controller but the Z axis step/dir be translated by my own PIC/AVR subsystem.

[sixtharmy]

Hi abasir,

I think that where the POSAM design goes wrong is in not utilizing available drawing/CAD programs to develop input to the inkjet manufacturing process. In the "Programming and Design" section of this forum over 20 programs are listed that will produce input for CNC processes. If I desired to make PCBs with an inkjet, then I'd like to be able to use a PCB design program like ExpressPCB or a 2D cad program like AutoCAD to electronically produce a design that the inkjet manufacturing process could turn into a usable physical object. If I wanted to do rapid prototyping then I'd like to be able to use a 3D CAD program like Solidworks to electronically produce a design that the inkjet manufacturing process could turn into a usable physical object. (For 3D work, there are programs, such has DRCAD that can slice a 3D file into a stack of 2D CAD files that can be printed sequentially on top of each other.) This ensures that the inkjet system can be used for a wide range of manufacturing purposes, but it requires that the system be capable of handling a wide range of different file formats. Inkjets are already capable of handling many of these formats, because they operate through print drivers.

With the exception of old pen plotters, the only thing that digitally controlled printers know how to do is put down dots. Thus, the only thing printer hardware understands is a properly formatted bit-map that defines the placement and properties of each dot. The task of taking a graphics file (egg) to a bitmap (baby chick) is called raster image processing and is performed by the print driver. What I hope we can do is handle everything from the original electronic design through the properly formatted bitmap with available commercial and/or open source software. What I propose building is a combination of hardware/firmware that will move the stage and fire the jets based on that bitmap to produce a chicken. I'll talk more about drivers soon, since their output defines what that hardware/firmware must do.

[greybeard]

Hi sixtharmy.

Having read your last posting, a slight frown crossed my mind.
You describe the printhead depositing the 'ink' using a simillar raster implementation as in the original machine it was removed from. But does this not conflict with the usual cnc machine set up, which essentially moves the 'tool' in a vector mode, with xy values moving the head at the same time.

Am I missing something, eg is there hardware/software mounted on the printhead that performs the last conversion of the necessary bitmap image input into the instructions to the jet nozzles to fire ?