changeable print head

I was wondering if anyone has thought about changable print heads similar to old style pen plotters? That would make multiple materials possible.

I'm not sure what you mean by this. I've never seen an old pen plotter up close. Presumably you mean something like what I, at least, have been thinking about: an area full of different heads, that the plotter arm/head-holder/meta-head could move along and drop/pickup heads from?

This does strike me as (one of) the next logical step(s). With a dedicated head area, some kind of head holder (or just a template of where to place the heads), a well-designed coupling system, and maybe (but not necessarily) an additional controller axis, it seems possible to change materials/techniques reliably. I'm no engineer though, so I'd love to hear the experts' thoughts on this. I've no doubt they've considered it already, if not firmly planned it for some point further down the line

"Presumably you mean something like what I, at least, have been thinking about: an area full of different heads, that the plotter arm/head-holder/meta-head could move along and drop/pickup heads from? "

yes its just like that.

The reason I ask is I am a mechanical engineering major at UTA who works in the Material Science Department and I am making this printer for composite ceramics. So I was just wondering if anyone had started this or if I need to start from scratch.

There has at least been some talk of using ceramics, and much talk of different materials (including solder, chocolate, etc.), print heads, nozzle sizes, material extrusion rates, etc.

The reprap shop (which just opened) mentions that you can add(/buy) a few more parts if you want to support multiple heads, so it does look like this has been done, at least by a few experimenters.

Definitely, spend some time talking to other reprappers before starting "from scratch"

"I was wondering if anyone has thought about changable print heads similar to old style pen plotters?"

Yeah, that's on the to-do list for Mendel, the next generation of RepRap, iirc. It might be an upgrade to Darwin, as well, depending on the work schedule and how many people are working on the different problems.

In earlier discussions on the list there has been talk about print heads in parallel. You simply move them both all the time and you extrude with the one where you want it to come out from. Otherwise the carousel would require more work with pics, motors, sensors etc. If you don't have the additional need to print with both at the same time, you can just install the head of choice and swap for a different job. Many of us have thoughts of this I'm sure. Just go ahead and work on the extruder and use what you want from what we have. We have some chemists here that will surely chime in if you pique their interest in the right way. They have been very active. Good luck. I'm looking forward to any progress you make.

The parallel approach has been some of the discussion and probably the most recent. The carousel approach has also been discussed earlier. I don't think that there is anything resembling a final decision within the RepRap community on the way to go with multiple extruder heads.

For my part I'm going parallel with Tommelise; one for HDPE and one for support material (spackling compound). I put the polymer extruder on with wingnuts so that I can easily swap it out when I want to go from HDPE to HPP or ABS or PVC.

Edited 1 time(s). Last edit at 05/24/2007 10:21AM by Forrest Higgs.

I can see a couple of problems with the parallel head idea:

Two heads in parallel reduces the work area by the distance between them so you need to keep that small. But if you make an object bigger than the distance between them then the inactive head will skate over the freshly laid down filament. Not sure how big a problem that would be.

My plan is to have multiple heads mounted around the circumferance of a vertical wheel. It would rotate to move the active head to the lowest point, moving the others clear. This scheme suits my machine which moves the head only in the z-axis and the job in XY, i.e. the opposite to Darwin.

For a Darwin style machine I think a carousel at the edge of the workspace and a means of picking up and dropping a tool is required.

Edited 1 time(s). Last edit at 05/24/2007 11:31AM by nophead.

The Dimension 768sst that i currently use has a dual head one for support material and one for model material so I dont think the skating accross material will be a problem but i need one for support and 3+ for material so I'm planning on going the carousel approach

You could do it in mechanics and software, rather than additional electronics.
Rig the table to descend to the lowest point, then a little further. The extra heads could be mounted above the rep-rap work surface, such that they descend a few inches when the table bottoms out.

Then the arm moves to the slot assigned to the current tool, the table descends, the arm moves slightly, (sliding the tool into a bracket,) the table rises a few inches, the arm tracks to the position of the next tool, the table drops that same few inches, the arm moves slightly, (sliding the tool out of a bracket,) and the table rises again, to the level of the current work.

The advantage of this is you only have to increase the RepRap size on one dimension, and you get nearly the full width and length for tool storage.

The lock for the bracket storage could be a comb that blocks all tools in when not fully descended, and a half inch slide in one dimension, for all tools, to keep them from falling to the work surface when the table is fully descended.

Connecting it to the arm could be similarly non-electronic. If the arm is in position, its gripper is open, due to an external latch, (similar to the latch that allows you to open the front of a VCR cassette.)

Just my two cents, which admittedly, have suffered from inflation.

My thoughts on the matter:
Build your printhead holder with a series of alignment pins an latches to hold it solidly in place, then put a pic on each printhead to control temp or syringe pressure or mixture ratios or whatever - thus the base machine only has to send out start/stop commands and possibly receive ready/notready and max speed data from the print head and the axis only sends docked/undocked data (the dock/undock commands can come from the toolholder/carosel). With this approch changing tools becomes just another move function for the machine (I figure a line of tools along one edge of the machine with feedstock coming in as filiments or via tubes overhead) the point is the machine does not need to know what it's printing with so the programing becomes much simpler and an infinate variety of heads are possible.

Just another .02 on the way to the big 1.00 in the sky
BD

> ... the point is the machine does not need to know what it's
> printing with so the programing becomes much simpler ...

Surely, the system as a whole *does* need to know what it is printing with -- max speed of movement, delays between layers, etc etc may well be material-dependent. That's why there are so many per-extruder preferences in the host software, I think!

Unless you want the extruder PICs to start talking to the stepper PICs directly with all that info (i.e. basically move many host software functions into PICs, which seems a LOT of work!), the host software will always need to know what extruder is is using and what the particular requirements of that extruder and its material are. Or am I misunderstanding your idea?

Jonathan

jmarsden Wrote:
-------------------------------------------------------
> Surely, the system as a whole *does* need to know
> what it is printing with -- max speed of movement,
> delays between layers, etc etc may well be
> material-dependent. That's why there are so many
> per-extruder preferences in the host software, I
> think!

Well, yes, but there are a finite number of variables that vary from extruder to extruder. Each extruder's respective PIC could be programmed to report its values for these variables (such as speed, delays, extrusion diameter, etc.) to the host software, which would use them "blindly" - it wouldn't have to know what material it was spitting out or why those variables were chosen, and it wouldn't have to have a host-side database of extruder profiles to match from.

Kyle

OK, now I think you are proposing a design change affecting (at least) extruder firmware, the SNAP protocol command set, and the RepRap host software. Maybe the extruder board too, if some extruders need sensors/feedback that the current extruder does not. I think that's probably too much change for pre v1.0.

Furthermore, in general, the host software development environment is a *lot* cozier for mere mortals to develop in than the PIC one, and there tends to be a lot more CPU power and memory available on the host... so moving more functionality into the extruder boards and their PICs is most likely making development harder, not easier. It may be that the benefits to the end user outweigh that, but IMO it needs thought.

We need a second extruder for support material for v1.1 (per the Future Plans page [www.reprap.org] this is v1.1, though if we need it to get Reprap to replicate, it seems to me it is really v1.0? Can anyone clarify this detail for me?). Adrian is working on 2nd extruder support now, which is why we're seeing all these changes to extruder prefs in the host code at the moment. Suggesting a major design change shifting complexity away from the host code and into the PICs now is probably not all that timely? I'd suggest holding off until v2.0 or so on this idea?? If you have the time/capability to implement a prototype using your design, that would be intriguing, but your changes might not make it into the main codebase for a while.

Jonathan

Personally, I think the client needs to know what it has to build with, as in the future, it may have to figure out if a given design presented to it, is manufactureable with the current set of extruders, or if the design needs to be modified to suit the available build materials.

However...at the same time, it'd be really nice if a user could just snap in a new extruder and the client could just say "Oh. Now I can work in powdered copper. Great." The drawback of this would be, either the heads have to tell the system a lot more than the settings mentioned above, but rather also, either "powdered copper", or some value that represents powdered copper to all the hosts, which means centralized standardization.

Somewhere between these might be a head that reports its spec range, and lets the client ask the user which material it's being used with, setting the specs from that.

Still, probably not for V1. Maybe V2.

theres no reason we cant go with a hybrid system with both options. currently, the firmware can and does identify itself. it should be possible that you connect an extruder to the system, the host software recognizes it and then prefills the values with the standard ones for that type of extruder.

since we are an open project, its easy to standardize on these default values and is something that should be rather trivial.

If we need to "know" what extruders are available, one really simple way to do this would be to assign fixed SNAP addresses to each extruder type.

We have 255 addresses to play with. We will only need 3 dimensions of travel (string theorists need not respond :-) ) . Leaving addresses 0 and 255 for some form of broadcast packets, and address 1 for some form of test or alternate board not yet invented, we still have addresses 5 to 254 for materials... should be enough for a while!? This assumes you only ever need one extruder of a given material type... some folks might want multiple extruders of one material but with differing nozzle widths... Even if we left say addresses 200 to 254 for "individual experimentation", that leaves 196 "standardized" extruder/material types. We could decide to leave a few addresses free at the low end for new board types not yet dreamt of, too.

The advantage of this (mis?)use of SNAP addresses is that it becomes trivial for the host software to ask "what extruders are available" by sending SNAP command 0 to each SNAP address in turn. Those that exist will respond. This requires no extra complexity in the extruders at all, just an agreed "standard" mapping of SNAP addresses to extruder types. It therefore seems to me to remain compatible with the work Adrian is now doing, yet allows the idea of "just plug in an extruder" to be tried.

Jonathan

The main reason I favor "smartheads" is that you eliminate the need to create, standardize, update and transfer to each machine a (potentially enormous) database of printheads/matierials. Also local variences (such as differences in heating efficency caused by better or worse insulation or wonky feed rates resulting from oddball but I had this laying around motors) can be locally accomodated and resulting heads could even be loaned out without touching the central firmware. Also the lack of a central, mandatory repository encourages Darwinian experiments in the can't hurt (or take long) to try it vein.

Given the tendency of any software to bloat, the idea of breaking off bits and simplifying them rather than piling ever more variables into a central repository seems hard to argue with. As the machine evolves new substances are bound to be extruded. Isolating the complications involved in working with each substance in the printhead means that each head remains relatively simple rather than trying to create a highly complex universal extrution control. As an example, I looked into a head to lay down foam rubber (insulation, cushioning etc.), the head to do this would require 4 or 5 fluids of differing viscosities be mixed immediately before deposition in ratios which varied depending on the degree of flexiblity and size of air pockets desired. Building the complexity necessary to handle that printhead into the main architecture of a hobbist machine that is going to be used for rough prototyping would be a huge waste. Now consider the possiblities of 2 part resin/catalyst mixtures which require UV light or ceramic slurries compacted with ultrasonic vibrations, not to mention the possibility of subtractive heads of various sorts, all with different warmup, predposit, deposition failure feedback, deposition end and shutdown procedures. I don't imagine anyone wants to wite that monolith from scratch or try to debugg it after 18 generations of accretion.

As for the complexity of pic programing I imagine that software for stock heads would be available for download; also modifying the relatively short, simple programing of a removable part is going to be much less intimidating/hazardous than poking about in your machine's main brain.

As I originally implied the printhead would initialize by sending a small amount of info to the motion control program. I mentioned max speed but other possible info would include filiment diameter, min speed, and toolhead offset. This data could be written into the motion control variables as they exist(I imagine, I am not really up to speed on the software, I'm a mechanic and a philosopher). Pauses between layers could be handled by having the printhead send a notready after each print and a ready x seconds later.

While it would be nice to have a machine which can be fed a set of plans with notes as to materials which it then spits out that also seems like a version x goal and would not be precluded by smartheads, the main brain would simply have a list of the heads available to it and a means to request them. It might even be able to program some of them (like my foam head) on the fly to produce the exact matierial/color/finish desired but for now I see hominids servicing the machines providing the requested heads and preping them as needed.

OK, I guess that makes.07.

@Jonathan:

You could need more than three axis when running a milling head on the RepRap. I know the current incarnation isn't rigid enough for milling, but who knows. Or a seesaw like head with two or more extruders attached, so the RepRap can switch heads on the fly. I can also see the need for two or more independent heads, needing at least three axis per head. Or a conveyor belt on the base for removing finished goods... lots of possibilities.

Anyways, I think it would be unwise to allocate only 3 SNAP addresses for axis, 10 or 20 would be better.

--Blerik

I think the way I would handle this is to have the head return an identifer, possible a string or integer id, and the use that in the host s/w to load a plug-in of some sort. A bit like when you plug in a USB device and the OS loads a driver.

That keeps the PIC firmware as simple as possible. The only complication to the host s/w is to create some sort of abstract interface to a head controller. People can then write thier own head driver plugings to do anything they want without having to hack the main host s/w.

---

[www.hydraraptor.blogspot.com]

i agree wholeheartedly with nophead. one way or another, we're going to need to store the settings for each different extruder somewhere... whether its on the firmware or on the host software. there is no way around this.

now, do you want to write those settings in C on a tiny microcontroller with little memory and poor debugging tools?

or do you want to write that stuff in java which is must easier to debug, maintain, and update?

personally, i think that the firmware should be as simple as possible as its a crucial part in the system that needs to JUST WORK. adding extra complexity at that level is asking for problems.

its really a moot point anyway, as we're currently doing it in java and none of the core contributors are going to rewrite the software to move it to firmware. if you think it is a better choice to do it in firmware... go ahead and do it!! if your solution turns out to be better, well then people will adopt it.

I also agree with nophead. In my own experience, I've had to tweak extruder settings quite a bit to get it working right, and I would absolutely *DREAD* having to reflash the firmware every time I did a test while developing a new extruder head (unless of course the settings can be updated on the firmware without reflashing). I think that if the main RepRap software can be reconfigured to utilize 'extruder plugins' then that would be ideal - basically, the plugin will tell the main RepRap software the physical dimensions of the material it extrudes (height and width of the extruded line, max extrude rate, etc) the main RepRap software will simply tell the extruder when to turn on and off, and the plugin will handle the rest. As I see it, this will allow a significant amount of flexibility in extruder heads without causing a huge headache in the main code.

I've quite enjoyed reading all the back and forth about how everyone wants to have an extruder head switching device for RepRap and how they want to do the mechanics and electronics. Has anyone given any thought to how filament feeds, and in some cases like some of the support materials and all of the conductive materials rod feeds are going to be handled in a way that avoids their getting hopelessly tangled?

i know that one of the methods for storing filament that vik was using was to use a 2 liter (or equivalent) bottle to store it... perhaps we could eventually mount that directly on the extruder, and then you only have to worry about the bottle clearances.

Quite frankly, yes.

My idea of mounting all the heads above the platform in a grid, or the other idea of a linear rack along one side, both account for this. The filament comes through where the tool was stored. If the filament can be taken back up, on my idea, or has a fishing weight threaded onto it, with the spicerack solution, (so gravity takes it up when the tool is reseated, but without enough weight to pull filament out of the dispensor,) you won't even get a mess when you put the extruder back.

Even with the carousel idea, you don't run into problems, as long as only one head is checked out from a carousel at a time. If two are checked out, you end up with twisted filament as soon as the wrong two heads are selected in the wrong order, and a twisted mess as soon as one is re-racked for a wrong third head.

Of course, all this depends on the filament being flexible over sufficient lengths. If the filament has to be provided in sticks, the only way to maintain this flexibility, would be to either make the head re-seat for a refill, or make the filament a chain. Imagine a brass chain running to the head. Pressed into the extruder with a toothed wheel, (that nominally engages the chain, but more often crimps it for purchase.)

Now, on to firmware/software storage of standards. I'd say the best solution would be to put flash memory on the head, and have it contain the settings for the extruder. Not as firmware, but as software settings to upload, or even plugins to upload. My reasoning is this. In the worst case scenario, someone will be using reprap without reliable access to the internet. Possibly without day to day internet at all. They may have internet when they get the head, or perhaps they get it from a neighbor. In any case, if the supplier doesn't think to provide the driver for the head with the head, the user is stuck. If the driver was stored on the head, but not necessarily part of the head, then where there is a head, there is driver software.

This doesn't require a major rewrite, as making the drivers firmware, but it would require more hardware. In itself a less than desirable outcome, as it'd drive the materials price up, and increase the BOM. Even if the materials eventually become practically "free", so long as there is some assembly required, more parts means more time and frustration getting one up and running.

That gets you into the whole question of home much material this "dispenser" must hold. HDPE and CAPA filament, for example, coil at about 300 -350 mm. 500 mg of the stuff is a considerable volume and the material is quite stiff. As a result of that stiffness it can't be treated like twine.

Your point about the need of a takeup mechanism is quite to the point though it misses the problem of the extruders in their present design tending to twist it causing additional problems.

This is completely aside from the problem of materials that are in rod form like waxes and eutectic metals that would be useful for making printed circuit boards. Different from all of these are support materials pumps handling things like spackling compound (eg, Pollyfilla).

Most people talking about dealing with multiple extruders heretofore, myself included, have tended to proceed from the notion of the plotter head carrel or rack of the sort that you used to see that handled a set of different width ink pens on old line plotters. That paradigm sort of works as long as you have a takeup mechanism for filaments and you are only using filament. Once you take in different kinds of materials that take on different forms things get almost impossible complex. I'm looking at a support material pump rather like what Adrian has been working plus a manually detachable polymer extruder (I use wing nuts) sitting side by side. I know there are limitations that that configuration put on a printer. I feel, however, that the limitations are a lot more bearable than the complexity of dealing with 5-6 different extruders handling different materials seem to imply.

Edited 1 time(s). Last edit at 06/22/2007 07:51PM by Forrest Higgs.

Look up how to make rope. the stiffness can be partially dealt with, I believe, by using a thinner strand, and winding it into a rope for the final thickness. Much the same way that multi-filament wire is more flexible than single-filament wire of the same diameter.

Again, look at my comment on chains of the stuff, although manufacturing of chains to handle the flexibility issue definitely increases supply costs. I think I like the idea of rope better.

As for twisting up due to the extruder. I hadn't thought of that. I can see two fixes. One, unwind it at the spool. Two, use two counter-rotating drivescrews to push it through the extruder, instead of one, preventing it from winding up in the first place.

Anything that can be handled by a pump, it'd seem could be handled by a tube running from the print-head to the supply bin. Perhaps not, at least for some of the higher viscosity materials, but it seems that a supply hose might be at least a partial answer.

Okay. Something to consider. How much material might need to be laid down in a single pass. Is that much, and no more, a sufficient load for an extruder head? If so, give it a "clip", or "magazine" that holds that much, and no more, and have it re-seat to reload. This would work for rods of wax, although it potentially makes the extruder head mechanically complex. A good way of making it quit working.
Even if the thing can hold exactly one rod of material, having it re-seat to get a new rod pushed into place, (I'm thinking glue-gun here), whenever the last one drops below some certain distance, (probably detected by an opto-isolator, located along the length of the drive screw, but near the top, or just calculated in software, although then small errors would build up.) This stays mechanically simple, The feed could also be reasonably simple. Rack them in such a way that one can slide into place, and fall into the feed hole, when the feed hole is pushed into place, (unlatching the feeder to isolate one stick, and let it slide forward and down.)

P.S. On rope...would air-spaces between the sub-filaments present any problems with either the extruder, or the project?

P.P.S. I, too, am thinking of a rack, but one in two dimensions instead of one. X and Y above Z. Open Z further than the tallest workable project to change heads.

Edited 2 time(s). Last edit at 06/22/2007 08:27PM by Sean Roach.

Rods are a pain. You either wind up with a lot of wastage in stubs or you find yourself welding rods together on the go so that you have a continuous strand. You can ask Vik how much fun that is. I've done the stubs route and that is very unpleasant. With the Mk II it entails demounting the polymer pump and pulling the stub out while the extruder barrel is hot. That is rather unpleasant work and wants the machine to be watched over, more or less, while it's in operation.

As to the rope and chain idea, when you can find a manufacturer, lets try it.

Chain would be...difficult. I was thinking that using pre-manufactured chain for any future direct extrusion of metal would handle the natural stiffness of the metal. I suspect, although I don't know, that suitable single-metal chain can probably be had from hobby stores. [www.hobbylinc.com]

As for rope. Bundle multiple strands together. Secure one end. Twist until it wants to kink. Release. Then wind the thing up on the spool of your choice.
My dad once made a climbing rope, from six ski-ropes and lots of bailing twine, using this method. He used a power-drill, with a bent nail in the chuck, to make the job easier.

I'll accept I have no experience with rods and reprap, but I have used a hot glue gun. In a hot glue gun, the feeder sits on top, and you just push a new rod in on top of the old when it gets low. With your screw, if you can seat a new rod while the screw still has purchase on the old one, then you can put an opto-isolator somewhere along where the screw loses purchase on the old rod, and can catch a new rod and drag it through. Basically signaling to the extruder either "full enough" or "needs more".

It appears you could drop in a rod after the other has gotten about half way down the polymer guide, on the latest extruder design, and the drive would catch the new while still having purchase on the old. At the point where it loses purchase on the old, the new would "catch up" and help push it through. Granted, during this stage, the extruder would be working, and not aware it was extruding practically nothing. I'm not sure on how feedback could be handled to prevent this. Possibly note the difference in resistance on the motor, signaling the motor is no longer under load. Possibly an opto-isolator pointed at the head, signaling whether or not something is coming out. Maybe one right where the system loses its grip on the old rod, so the gap is detected, and the robot quits moving the head, or lifts it, until the gap has closed.

It might also be possible to use a drive shaft that has deeper, but finer threads on one end, and courser, but shallower, threads on the other. The new stick would easily catch on the shallower threads, and be propelled along further per revolution, but also easily slip against those threads when it met up with the old stick...possibly into the heated area itself, to encourage the two to weld right there.

Okay. I've laid out my thoughts on the matter. I'm working more and more off speculation, so I better hear what you state next, and save the rest of my thoughts until I actually have a part in my hand.

I think the joining one end to another wouldn't be a big problem as long as you can thread in the new material before the old one leaves the threaded piece (maybe as soon as you can, maybe a sensor to warn/activate next feedstock), at which point pressure ceases. If you get the new piece in in time, it will follow behind the first one and push it out. That is assuming that the path is able to be followed without needing to be aligned manually to get in the tube. Depends on alignment and fitting I guess.