What marlin still needs for multiple extruders

I'm sure there are a bunch of different ways of goign about it, but here is what I personally see as the best, based upon experience with skeinforge/sfact/slic3r/kisslicer.
---------------------------------------------------------------------------------------------------------------
First, there are three general implementations of multiple extruders I have seen so far which show a lot of promise:

1) Multiple complete extruders strapped together (makerbot, bfb 300)

Pros: Simple and intuitave
Cons: increased movign mass (for moving extruders)
extruder droolover part while not in use
Z height for each extruder tip must be perfectly level

2) Single extruder motor, second motor for a filament selection cam shaft (http://www.thingiverse.com/thing:16429)

Pros: only two motors for theoretically up to ~4 filaments
Cons: increased movign mass (for moving extruders)
extruder drool over part while not in use
Z height for each extruder tip must be perfectly level
Requires more customized parts for the cam


3) Two complete X axis assemblies with independent X movement

Pros: No increased in movign mass
No drool over the part (second extruder parked while first is printing)
Tolerant of small z offsets of nozzle tips (can adjust z between heads since both nozzles are not over the part at the same time)
Cons: EXPENSIVE (needs everythign for a second X axis)
Practical maximum of two extruders



I'll personally be attempting option 3 since there are few people workign on it as far as I can tell.

--------------------------------------------------------------------------------------------------------------

To make any of this work with more than a single firmware, Marlin needs to be capable of a few new tricks:

A) Independent PID control of each extruder temperature.

All temperature readings should use a table. There is no reason the AD595 should have a seperate method when it can easily be put in a table the same way as the various thermistors are.

Once all the various temp sensors are done with the set of tables, the config.h should be simplified to the following (or similar):

//#define EXTRUDER_1_TABLE 1
//#define EXTRUDER_2_TABLE 1
//#define EXTRUDER_3_TABLE 1
//#define HEATED_BED_TABLE 2

Usign the notation 1,2, and 3 for extruders instead of 0,1, and 2 makes much more sense from a practical standpoint. Hopefully it won't make the code much more complicated.

I think it's reasonable all three extruders should use the same PID settings and steps per mm, as they would more than likely be the same types of extruders. Make sense to everyone else?

Settign each extruder temperature should be similar to the way it is done in teacup, using M104 P(extruder number goes here) S(set temp)
I'm open to better suggestions though


B ) Ability to save and recall the current X,Y,Z or E location

We need a G command to save the current position so it can be recalled after an offset is aplied to the toolhead(s)
Ideally using an X,Y,Z,or E after the G___ command would save the current position for every axis called.

For example, G___ Y would only store the current Y location value, G___ XYZE would store all the XYZE values
Recalling a value would be Another G-code (maybe 1 higher than the previous G___) So G___+1 X would set the saved_X to the current_X position. G___+1 XYZ would set the saved_ XYZ to the current_XYZ location
(leavign any uncalled axis alone)



C) Reassign pinouts and set offset when the different toolheads are called

Instead of treating each extruder motor as a seperate object, wouldn't it be easier to just change the pin definitions for different toolheads (and save on memory)?

For example, lets say Extruder_1 has step and dir defined as pin 1 and 2 respectively, and the second extruder is pin 3 and 4.
When T1 is called, E_STEP_PIN AND E_DIR_PIN are set to 1 and 2, when T2 is called E_STEP_PIN AND E_DIR_PIN are set to 3, and 4.

Also, this approach works well when applied to havign a second X axis/extruder assembly (implementation 3) as it allows simple control of another mostly identical axis and endstop without a lot of new code.
In the case of implementation 3, you would be redefining the X_STEP, X_Dir, E_STEP, E_DIR, X_MIN and/or X_MAX pins when a toolchange is called)

Some of these controlls seem redundant, but for better or worse there are a lot of slicers around at this point doing things a bit differently, and to maintain some level of cross-compatibility and flexibility, I feel all this is necessary.


Unfortunately, I'm not skilled at all when it comes to coding, and an outline is about as far as I can go towards implementign the software part of this.

Thoughts/opinions/criticisms?

---

www.Fablicator.com

I think you left out a 4th option, which would be some kind of tool change arrangement. I guess it doesn't make your list because yours is a list of things people have worked on. This one is on my to-do list, but not near the top.

Cons: Increase in moving mass and complexity. Probably comparable to the filament selection cam method (possibly less).
Pros: Single X axis, extra hot ends don't drool on the part, variable number of tools per machine, potential for other tools (mill, knife, probe, etc.) without manual changeover.

I don't know how practical this would be, but what about a single extruder and nozzle with a dye injection chamber that colors the filament right before it's extruded?