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.

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

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

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.

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. :)

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.

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.

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?

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/articles/mi_m0HPJ/is_n6_v43/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/articles/mi_m0HPJ/is_n3_v48/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/articles/mi_m0HPJ/is_n3_v48/ai_19540806
http://www.findarticles.com/p/articles/mi_m0HPJ/is_n3_v48/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

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.

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.

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 ?

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/articles/mi_m0HPJ/is_n6_v43/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/articles/mi_m0HPJ/is_n3_v48/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/articles/mi_m0HPJ/is_n3_v48/ai_19540806
http://www.findarticles.com/p/articles/mi_m0HPJ/is_n3_v48/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


Hi all,

I just had a quick scan thru this thread, so not completely sure of what is going on, maybe you should look to the way the original discovery was made for the invention of the inkjet printer printer principle. I believe it was a accident in some Scotch 3M lab, a technician while using a shringe to fill some ink into a cartridge of some thing or other accidently dropped it across a power supply connection causing the metal part of the shringe to heat up and violently eject the ink out.

Not sure if this is true or just one of those myths that seem to crop up from time to time.

Either way maybe you should consider the method (whatever it be) of ejecting the ink (whatever liquid) as a forth or fifth axis to a cnc machine. This way it may be possible to use existing G code conventions to control the ink ejections.

Mike

sixtharmy,
Looking from your last comments, I believe what we'll need is something like the in the graphic below. We need the modified gcode because CNC works like plotter (spindle on, move to XYZ, ...) rather than inkjet (move & spray, move & spray). Writing a printer driver is beyond me. As far as the CNC controller, maybe start with TurboCNC (source available with registration) and modify it to talk to the two drivers. There's enough electronic gurus at this site so I believe developing the printhead driver would not be a major problem.

Hi Greybeard, Hi Abasir, Welcome madmickiii,

Inkjet printers are raster devices. Even graphics files in vector based languages like Postscript are transformed into a bitmap by the raster image processor of the printer driver. Having produced a bitmap the driver then cuts it into swaths. Each bitmap swath contains the data that the printer needs to deposit ink during a single horizontal pass across the paper. The driver then packages this data with the proper higher level (Epson escp, HP hpgl, etc.) commands to operate the firmware/hardware of the printer and sends that swath’s commands and data to the printer engine.

In the case of Epson printers, most of this data goes out in the form: topmost black jet, leftmost dot value, next dot across the page value, next dot across the page value and so forth until the right most dot on the page value has been given. The file then contains a string for the next jet down and another for the next jet down and so forth until it has given a string for every black jet in the column. Following this the file contains strings of horizontal values for all the jets in the cyan column and so forth until it has given every jet a dot value for every position it can take in the pass across the paper. I suspect that the print engine takes all this data and recreates a bitmap of the swath in a two dimensional array in ram (In fact, I think it produces a bitmap for each color.) The engine can then pull the values for the whole column of black jets for the leftmost position on the paper use them to sequentially fill the latches of the piezos on the print head and then fire the whole column with a voltage pulse. The head then moves one position to the right and repeats the process for all the black values in column two of the array and so forth until it’s printed every column in the array. A similar process (with offsets for their physical position across the head) is performed for the columns of color jets. When the whole swath has been printed the printer informs the driver to load the next swath. The new swath instructs the printer to advance the paper an appropriate amount loads the bitmap(s) with the dot values for the next pass and repeats the process.

I am simplifying here a bit. For instance, if your graphic file consisted of a 1 inch square block in the middle of an 8 and ½ by 11 inch sheet, then you’d first see a command to drop about 5 inches down the page and a command to move about 3 and ¾ inches across the page followed by the data for a series of one inch long passes. I’m out of time now, but I believe that we should retain a driver, because of the complex preprocessing that it performs, and focus on producing a print engine that transforms the driver file into firing jets and moving platforms. Later.

Hi guys,

Ok,
Maybe I am being dense (not the first time) but I don't think Your idea is coming accross clearly Sixtharmy.

What I've gotten from reading the post (twice) is you basical want a machine that looks like a CNC gantry (for example) that acts like a conventional printer with maybe the possibility of a z-axis depth move (for all of those rappid prototyping people). But you want to be able to make it work similar to a conventional printer so that you can use the currently available software for converting to printer style formats (I assume for flexability).

So basicaly a big flat printer! But since no one in that industry is going to give you their software (or hardware for that matter) you want to create your own (as inexpensively as possible).

So in summery : 1. Control via conventional printer software from a Pc
2. Made from redily available components.
3. be able to use anyones ink/injet head.

Hurdles:
Interface for conversion from standard Pc software to a compatable control (to be made) language.

sixtharmy - thanks for the clear description of the graphics process going on. Your direction is becoming clearer to me. But then so is my lack of appropriate knowledge to contribute.

However I shall continue to follow carefully and wait for the opportunity to add some flash of inspiration. :D

I see better what you want to do. I guess the boxes in red below are apps/hardware/firmware that needs to be designed & developed. I can say it's not gonna be easy. For a typical letter size printout: 8" x 300dpi x 11" x 300dpi x 8bits/color x 4 (CYMK) = 253MBytes... I don't even want to estimate the expected GCode file size.

Hi Miljnor,

The only thing I can fault in your summary is that the positioning hardware need not be a gantry, but you only give this as an example. Otherwise you’re spot on. What needs to be designed and constructed to fulfill the requirements you enumerate and run an inkjet head mounted on a CNC machine is what the printing industry calls a marking engine. This engine takes the commands and data output by a printer driver and uses them to move the head/paper and fire the appropriate jets. I see four ways this might be accomplished.

1.Modify an existing commercial printer’s hardware/firmware.
2.Emulate the engine in PC based software and interface through a minimal amount of hardware.
3.Manufacture an engine using a programmed microcontroller and some additional hardware.
4.Utilize a System on chip (SoC) printer engine with a chip maker reference design and firmware application development suite.

As I’ve mentioned, I’ve tried modifying some consumer grade printers and it’s a bear. However, I haven’t looked closely at any great big commercial wide carriage pedestal mount type inkjet printers, so I can’t discount that they can be modified. If so, then older commercial printers can be obtained at auction for a reasonable price, and this may be an appropriate avenue to our goal. Additionally, I haven’t looked closely at anything but Epson printer marking engines (Well, a bit at HP and Cannon). These don’t appear to be amenable to modification, but there could be some that are. Again as I’ve mentioned, HP printers may have firmware that can be altered, and I have a thought about Lexmark printers that I’ll mention below when I discuss SoCs. I don’t want to totally ignore this approach. It may turn out to be the simplest and cheapest. We’ll have to see. At the moment it doesn’t look terribly promising. Here’s a link to a site describing an older Lexmark modified for 3-D printing, but it seems sort of crude: http://www.sci-spot.com/Mechanical/3dprinter.htm

The second approach is the one taken by the POSAM group. For inkjet control, they used a National Instruments DIO32-HS PCI GPIB board inside the PC to connect to two exterior boards. The first board accepts input over an external cable from the GBIB, and passes most of that data through to the second board unchanged. Some of the signals from the GBIB are used as input to a DAC on this first board. The DAC converts them into a wave form that is voltage amplified by an on board op-amp and this wave form is passed to the second board. The second board is just a cable adapter. You plug a big external cable from the first board to one side of it and a small thin ribbon cable that runs to the print head to the other side. For positioning motor control, signals are output from the PC over an Ethernet connection to a commercial 6K4 servo controller. All of the control signals running over these lines are generated in software.

For our purposes, I envision that a driver will output a swath at a time to a virtual parallel port that is part of a virtual printer. The virtual printer will then arrange the swath data for output to the print head and translate the positioning commands so that they can be understood by a motor controller. The virtual printer will then pass these commands to the print head and controller over some sort of interface. The difficulties with this approach lie in writing the software code for a virtual printer and finding inexpensive hardware for the interface. I can’t comment much on the programming. I’m not a programmer. I’ve been trying in this thread to give a programmer an idea of what such a virtual printer would have available as input and what sort of output it would need to run a print head. I assume any programmer here would understand the requirements for motor control. I’m going to continue spouting everything I know in the hope that some programmer will suddenly realize, “Hey, I can do that.”

Concerning the interface I do have some ideas, but I’m not really a hardware maven either, so I may be far off base. I hope someone with greater experience will put us on the correct path here. Used National Instruments interface cards run about $ 300 on ebay and are probably too expensive for our purposes, but GBIB has the advantage that there are compatible programming languages, like Labview, that are designed for interfacing with instruments to pass motor controls and data. However, the software is also expensive, so I think the POSAM type interface may be too expensive for us. If anyone knows better, then please correct me.

Another possibility is to use parallel interfaces much like many motor controllers. Multiple IEEE 1284 ports can be installed on a PC, and parallel PCI expansion cards run under $20. In this configuration one port might pass motor controls, while another passes inkjet data, and a third passes data for the jet pulse. These ports may be run bi-directionally so they should serve the purpose. Does anyone have any experience with this type of interfacing? Another thought that occurs to me is that every motherboard now comes with a DAC in the form of a sound chip. It might be possible to use externally amplified sound port output to drive the inkjet pulse. One thing that concerns me here is timing for all these various ports. I’m open to all suggestions on the subject of interfaces for a software type design. Any references to information would also be highly appreciated.

The third approach is the one used by the Parallax kit that xaq referred to in his comment. Here a Basic stamp and a small custom board are used to drive an HP head with output from a serial port. I’m probably going to order one of these kits if only for the programming book and I’ll let everyone know what I think of it. What I’m proposing that we build here is considerably more complex, but the principles should be the same. I know that there are people on the forum with microcontroller experience. Is anyone up to this sort of challenge?

Lastly, there are several chip producers (Agere, TAK imaging, ST Microelectronics, and Zoran) who produce system on chip (SoC) printer engines. Using these devices would be much like the third approach, but somewhat simpler. They’re comprised of an ARM type microcontroller packaged with a lot of circuitry to interface with print heads, motor controllers, RAM and PCs and also to perform the types of data manipulation needed in a marking engine. They’re programmed using fairly open microcontroller languages. Most manufacturers offer reference design boards and software libraries specifically to apply their products to running inkjets. In quantity the only chips cost about $10-20, but mounted on reference boards and with software I doubt any of these will be cheap. I still have to check. Lexmark uses the Agere chip in there latest boards so here’s another commercial design that we might be able to modify through rewritten firmware.

That’s all I have time for now. (I’m sure everyone thinks it much more than enough.) I eagerly await your comments. They’ve already proven quite helpful.

wow. that parallax board\cartridge is pretty great. I beleive I may purchase one. It seems like a very easy way to begin making a rapid prototyping machine using the binder and plaster method... swell.

I Thought I’d take a minute to explain why I favor Epson print heads over any other.

Most manufactures of consumer inkjets use thermal expansion to drive ink from their print heads. This technique was first discovered in the mid 70s by a technician at Cannon who observed a drop of ink shooting out of the needle of a syringe that he accidentally touched with a soldering iron (Yeah madmickiii, it’s true.) Cannon promptly called this process the “bubble-jet,” because a bubble of water vapor was found to form at the point of heat application and the expansion of that heated vapor bubble was found to force a drop of ink from the needle (jet orifice). Around 1986 HP found a way to inexpensively manufacture a bubble-jet cartridge and head combination using photolithography, and ever since they’ve been the leading producer of consumer inkjets. Around 1994 Epson entered the market with a different technology.

There’s a class of natural and manufactured materials called Piezo crystals that have the unusual property that when they are deformed (squeezed) they generate a static charge. This property has been exploited in some lighters (the kind that go click when squeezed) to generate a gas igniting spark. These materials also have the reciprocal property that when a charge is imposed across them they deform. Epson print heads have a Piezo material above each jet. When a voltage is imposed across the Piezo it changes shape so that the ink chamber above the jet is reduced in size. This pushes a drop of ink out of the jet. In short each jet is a tiny electromechanical pump.

Thermal heads are pretty much restricted to water based solutions. Most other solvents will burn at the temperatures to which a thermal jet would heat them. Apart from being a fire hazard, combustion byproducts would probably foul a thermal head. Also, since the manufacturers never envisioned these heads being used for anything but aqueous solutions, they’re often made of materials and with adhesives that would dissolve in other solvents. In addition, thermal inkjets can’t handle fluids with a viscosity much above 5cP (about the viscosity of whole blood). Piezo inkjets don’t suffer from these limitations. If our aim is to produce a device which can be adapted to many applications, then I think we should go with Epson Piezos inkjet heads.

Both Piezo and thermal heads seem to be driven in the same way. I described it earlier. There are serial lines that load fire/don’t fire values to each column of jets and a voltage pulse that fires all columns of jets. The only big difference is in the waveform used to fire the jets. Though I’d like to focus on Epson heads, anything we develop could easily be adapted to thermal heads. I’ll talk some more about drivers and why I’d like to retain them next.

Well, it’s been a long holiday, but once more into the breach.

I favor retaining graphics drivers in our system, because it will allow us to keep using the large available library of graphics applications. To follow any other course would mean that we’d have to develop not only the hardware/firmware to run the marking engine, but also an application for creating graphic input for that engine. This strikes me as reinventing not just the wheel, but also the cart, the horse to pull it, and the road to drive it on.

Almost all consumer grade printers run via a printer driver, and they’ve done so roughly since the advent of Windows 95/98 in the late 1990’s. In this sense almost all printers are now Win printers even if they’re running OS X or Linux. Prior to this, in the DOS/Windows 3.1 days, every software house that created a program that produced print output also had to produce a program that would turn their program’s output into a series of commands that a would run a printer. Of course each manufacturer and each printer from that manufacturer needed a different driving program. So if on your top of the line Pentium 1 machine in 1991 you needed to print a Wordperfect document on your Gemini 10X dot matrix printer, then you had to use Wordperfect’s Gemini 10X driver; and if on the same machine you needed to print a graphic from an early version of Autocad, then you had to use autocad’s Gemini 10X driver. I f you had to print from another program or to another type of printer, then you had to use yet another driver. These drivers were written in hardware specific languages like HPGL and ECP2. Software developers were not happy with this state of affairs, since they had to devote a lot of time to writing drivers; and hardware manufacturers weren’t thrilled, because they often developed devices with features (read selling points) that no one could take advantage of for a lack of software.

Windows 95 introduced the Graphics Display Interface (GDI). Software developers had to devise compatible output to feed the GDI and hardware developers had to develop drivers that would accept data from the GDI and turn it into commands to run their devices. (Incidentally, this included not just printers, but also graphics display cards.) As these drivers were developed, hardware manufacturers realized that much of the processing that they had been performing in hardware on the printer could now be carried out in software on the host computer. A good example of this is the Postscript printers introduced by Apple for their Mac systems in the late 1980s.

PostScript is what’s called a vector based graphics programming language. For instance to describe a one inch diameter black circle in the middle of a letter sized sheet of paper, first postscript describes the paper, then it describes the center of the page, then it gives an equation describing a one inch diameter circle centered there, and finally it describes a black fill for that area. This produces a pretty compact file that describes what should be printed on the page. Of course this means nothing to the printer, since the only thing it knows how to do is put dots on paper. In Postscript printers the hardware of the printer translates this page description file into a raster image of dots and presents the raster image to the printing device in a form that it can use to produce hardcopy. In more modern printers these same functions are performed by the driver software.

Print drivers carry out a number of pretty complex functions. They take a file of some format (.ps, .pdf, .jpg, .tif, .bmp, etc.) that somehow describes what’s to be printed on the page and from that description produces a raster image of dots at the resolution you specify. Note that until this first conversion is made the file (except for bmps) doesn’t say how many dots to produce to form the image. That is to say that the graphics file is independent of the reproducing device until it has been through the raster imaging process in the driver. Typically the driver then massages the resulting bitmap to produce a visually pleasing image of dots by applying halftoning, dithering, color correction, and other complex processing algorithms. The massaging is done so that the light reflecting from the pigment deposited by a number of dots that are smaller than the eye can perceive will combine to produce a desired color and darkness at a level where the eye can see. I don’t want to spend too much time on this massaging step except to say that for our purposes we need a driver that doesn’t massage the bitmap to make a pretty picture.
Lastly, the driver cuts this bitmap into horizontal swaths that represent the drops that the printer is to deposit each time the head passes over the paper.

This last step deals with the enormous file problem that Abasir noted. ( For a giggle sometime try the “save to file” option of your printer driver on a 4x6 photo at high resolution, but make sure you have a lot of empty space on your hard drive.) Since only one swath’s worth of data is output at a time, much less memory is required. In addition, the driver seldom delivers that data at higher than about 360 dpi and the head must make several passes to deposit drops at any higher resolution. (i.e. Place a 17.6 micron wide drop every 70.6 microns (360 dpi). Move over 17.6 microns and place another series of drops every 70.6 microns. Do this 2 more times and you have a solid line of 1440 dpi.) So a single pass of a six color inkjet with 96 jets per color across an 81/2 inch sheet only requires about 1.8 Mbytes. The driver also packages the data with head and paper moving commands so it need not necessarily describe every possible dot on the page. For the circle example above, before supplying a swath’s worth of data, the driver would first instruct the printer to advance the paper to where it needs to be to position the head to print that swath and then would use back and forth positioning commands so that the head would only need to travel a distance commiserate with how much of the circle its depositing on each pass. There’s also a process the driver performs called weaving that deals with utilizing the jets so as to lay down vertically adjacent swaths in the most efficient manner.

Well all the stuff that the driver does is pretty complex. Fortunately, there’s a Linux driver GutenPrint (formerly gimprint) that will do all these things, while also allowing us to turn off the unnecessary massaging functions. As a result, all we’ll have to deal with in our marking engine is the machine specific code for swaths worth of data.

Once again, sorry for what must seem to be endless posts. I've been thinking about this for quite some time without anyone to discuss it with. Much of my blathering comes from simple frustration. Later

Im gonne try to help a bit. I worked in the design of a digital printer, so iknow a bit of how thinngs works, on those machines. Cause what we did was a big format machine images were huge, so there was a software called the Rip would make the 4 different color planes CMYK acording to some parameters as how many dpi, how many heads the machine has. This can be done in photoshop(il try to remember and do a little ample here) there are also several algorythms to do this process. then that file was sent to the pc that runned the machine and from there the data was sent to a buffer. A control would get the movement of the heads and at determined position the encoder would start sending its pulses to the electronics to fire the printhead and the buffer would start to get empty so the pc should keep it filled. then advance the papper. And do the cycle again.
Of course there is a lot to more to digital printing.
The printheads were from spectra and costed arround $300usd with the ink tank.
Well i just made files, i had an image in RGB, then turned it into CMYK, splited the channels and get 4 images. Then i have to turn those images into bitmaps cause thats the info the Printhead needs drop or no drop so its a bitmap. Then thats what all about, to send that info to the correct jet at the correct time. I posted the merged 4 color layers and thats whats the image is gone come out.
Hope it helps.

i think the last image didnt upload right so her its again

Try this;

Go to a DOS PC and find GRAPHICS.PRO and GRAPICS.COM files. They are usually in the DOS directory.

Using these drivers, you can write a screen print program that is easily enacted in DOS by a CNTRL (whatever) command. OUr cam design softwere supplier did it when we pointed it out to him.

I would think that a sharp individual might be able to get an HP printer to do the like with this free driver/interfacing system.

I don't know if this thread is still alive, but I can probably help you out a little bit since I have built something close to what you are describing. What I built was a 3 axis printer out of an HP inkjet printer, an HP scanner, and a servo. The parts from the printer handled the x motion and the ink output, the parts from the scanner handled the y motion, and the servo moved the printhead vertically about 1.5 inches for the z motion. If lots of vertical motion is needed then a z table could be used or built.
I wrote my own software to open an AutoCad HPGL print file, and then process that information into stuff that my own controller board can work with - essentially output this dot, using this nozzle, at this x,y,z position.
The information is sent over the parallel port to the controller board. The controller board uses several MicroChip PIC16F877s to control the movement of the print head (1 for x, 1 for y, and 1 for z), the sensors, and nozzle output. The only other thing that is really necessary is the power supply for the printer that outputs +/- 5, 12, and 30 V.
As for the physical building of the printer, I used a piece of 3 foot by 3 steel sheet for the base. Used 1 foot tall, 1 inch diameter steel rod for the towers, connected the bars and drive motors from the scanner between the y-axis towers, machined a piece of 1/4 inch aluminum plate to hold the the print head, bars, and motors from the printer, to the bars from the scanner. Finally, I machined a new cartridge holder so that it could slide vertically about 2 inches, put a rack gear on the back of it, modified an RC servo to rotate continuously, and put a worm gear on the servo to mate with the rack.
That's all there is to it.

NOTE 1: I used HP stuff because I had it in a surplus pile. HP thermal inkjets should not be used to dispense flammable liquids. I would use an Epson piezo print head if I needed to dispense anything that wasn't water based.

NOTE 2: I used MicroChip PIC controllers because I personally prefer them. A Stamp, AVR, SX, Intel, etc. could be used instead.

And thanks for mentioning my HP 550 bioprinter - that's how I found your post.

This 3-axis printer sounds fascinating. I've been thinking about building something similar. If you don't mind my asking, what kinds of surfaces do you print on? I am interested in printing onto small plastic sculptures with irregular surfaces that have recesses and grooves, so the inkjet nozzles would be separated from the work surface by 1/2 inch or more in places. Do you have experience printing onto surfaces like that?

Jonathan Miller
Washington DC.


I don't know if this thread is still alive, but I can probably help you out a little bit since I have built something close to what you are describing. What I built was a 3 axis printer out of an HP inkjet printer, an HP scanner, and a servo. The parts from the printer handled the x motion and the ink output, the parts from the scanner handled the y motion, and the servo moved the printhead vertically about 1.5 inches for the z motion. If lots of vertical motion is needed then a z table could be used or built.
I wrote my own software to open an AutoCad HPGL print file, and then process that information into stuff that my own controller board can work with - essentially output this dot, using this nozzle, at this x,y,z position.
The information is sent over the parallel port to the controller board. The controller board uses several MicroChip PIC16F877s to control the movement of the print head (1 for x, 1 for y, and 1 for z), the sensors, and nozzle output. The only other thing that is really necessary is the power supply for the printer that outputs +/- 5, 12, and 30 V.
As for the physical building of the printer, I used a piece of 3 foot by 3 steel sheet for the base. Used 1 foot tall, 1 inch diameter steel rod for the towers, connected the bars and drive motors from the scanner between the y-axis towers, machined a piece of 1/4 inch aluminum plate to hold the the print head, bars, and motors from the printer, to the bars from the scanner. Finally, I machined a new cartridge holder so that it could slide vertically about 2 inches, put a rack gear on the back of it, modified an RC servo to rotate continuously, and put a worm gear on the servo to mate with the rack.
That's all there is to it.

NOTE 1: I used HP stuff because I had it in a surplus pile. HP thermal inkjets should not be used to dispense flammable liquids. I would use an Epson piezo print head if I needed to dispense anything that wasn't water based.

NOTE 2: I used MicroChip PIC controllers because I personally prefer them. A Stamp, AVR, SX, Intel, etc. could be used instead.

And thanks for mentioning my HP 550 bioprinter - that's how I found your post.

Is anyone pursuing this anymore?

I am very interested.