Extruder swapping

The neat click-in click-out extruder mounting made by my MSc student Arman Ghandizadehdezfuli that is on the blog has highlighted something: swapping extruders in and out of the Darwin design is a bit of a pain. I was wondering about making a design addition to Darwin to allow extruders just to be plugged in and unplugged. This would be a manual operation, but it would allow you to have four or five lying on the bench and to connect one up in a few seconds.

But it does mean a design change at this late stage. What do people think?

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Adrian Bowyer Wrote:
-------------------------------------------------------
> The neat click-in click-out extruder mounting made
> by my MSc student Arman Ghandizadehdezfuli that is
> on the blog has highlighted something: swapping
> extruders in and out of the Darwin design is a bit
> of a pain.

Adrian, You've got to tell us where your MSc student is from, or if he is British, where his family hails from. That family name is fascinating.

> I was wondering about making a design
> addition to Darwin to allow extruders just to be
> plugged in and unplugged. This would be a manual
> operation, but it would allow you to have four or
> five lying on the bench and to connect one up in a
> few seconds.
>
> But it does mean a design change at this late
> stage. What do people think?

I kept it simple on Tommelise and just used some 1/8 inch bolts and wingnuts. Those let me mount and demount an extruder with a minimum of fuss in maybe 15-20 seconds.

that depends on what exactly you're proposing to change in the design.

if its mechanical, as in the actual mount of the extruder to the carriage, then go for it. there are very few people with actual machines and extruders that its unlikely to effect anyone.

i do like forrests suggestion of wingnuts. it makes things alot easier =)

if you are proposing an electronics change, then it gets a bit trickier. we could definitely do it for the next version of the board, but the RRRF has about 80 in stock, as well as ~200 in the wild. as long as the electrical connection stuff is backwards compatible, then its cool.

No - this would be a purely mechanical change (if "mechanical" includes a plug and a socket). The extruder would have a projection which would click into a holder, and the plug on it would mate with the socket on the existing carriage connected to the existing PCB.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

cool, that sounds awesome.

Adrian,

I may be misunderstanding how this will work... please enlighten me :-)

How will the host software learn which extruders are available, and which one is currently plugged in to the Extruder controller? If all extruders use the same controller board, all are at the same SNAP address... how can each extruder head then carry with it any info at all about itself which the host can retrieve and make use of to control it?

I like the simplicity of one controller for all extruder heads, but I don't see how it fits with previous discussion of storing extruder data with the extruder, nor with the current approach to extruder preferences in the host software? Unless *some* kind of data storage is on the piece of the extruder that is swapped, I don't see how you can reliably keep the host informed of what is going on in any kind of automated fashion. Will we need an "extruder swapper controller" that can inform the host which extruder is currently not in the holder??? Or a separate on-extruder-head serially readable EEPROM, or something like that?

Practically, when you borrow your friend's wonderful new special purpose gold extruder (or whatever fancy extruder it is!), and you stick it into your Darwin's extruder rack, how do you tell your system about it, or (better) how does your system automatically learn about it now being available for use and what its characteristics are? Later, when he takes it home with him, how does the system learn about and adjust to this loss of capability?

At first glance, it appears that moving to a "one controller for all extruder heads" model will require a significant (and as yet completely unspecified and untested) change to how the host software learns about the available extruders. The current model (give each extruder a different SNAP address, poll the network to see which extruders exist, and store the per-extruder info in the preferences file on the host) may be slightly inelegant, but it is clear and pretty simple to understand. What am not seeing/not understanding about your proposal?

Jonathan

There's a distinction between what I'm proposing for Darwin: easy
exchange extruders by hand; and what I'm proposing for Mendel: auto
extruder changing.

For Darwin there's no problem. There are two controllers on the
carriage and two extruders. You change the parameters when you need to
by hand in the preferences file (or just symbolic-link to one version of
the file or another). Most of the time you'll only have two extruders
anyway. The quick-unplug scheme is purely driven by how fiddly it is to
swap them out at the moment to recharge them and so on.

For Mendel I propose just one extruder controller and just one piece of
extruder controller firmware that handles all extruders. Each extruder
will have a known parking place in the machine and its own parameters in
the file, so there shouldn't be any confusion. We could have a set of
jumpers on each extruder to give it a unique ID to make things even more
robust.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]


RepRap Forum Mailer wrote:

> How will the host software learn which extruders are available, and
> which one is currently plugged in to the Extruder controller? If all
> extruders use the same controller board, all are at the same SNAP
> address... how can each extruder head then carry with it any info at
> all about itself which the host can retrieve and make use of to
> control it?
>
> I like the simplicity of one controller for all extruder heads, but I
> don't see how it fits with previous discussion of storing extruder
> data with the extruder, nor with the current approach to extruder
> preferences in the host software? Unless *some* kind of data storage
> is on the piece of the extruder that is swapped, I don't see how you
> can reliably keep the host informed of what is going on in any kind
> of automated fashion. Will we need an "extruder swapper controller"
> that can inform the host which extruder is currently not in the
> holder??? Or a separate on-extruder-head serially readable EEPROM,
> or something like that?
>
> Practically, when you borrow your friend's wonderful new special
> purpose gold extruder (or whatever fancy extruder it is!), and you
> stick it into your Darwin's extruder rack, how do you tell your
> system about it, or (better) how does your system automatically learn
> about it now being available for use and what its characteristics
> are? Later, when he takes it home with him, how does the system
> learn about and adjust to this loss of capability?
>
> At first glance, it appears that moving to a "one controller for all
> extruder heads" model will require a significant (and as yet
> completely unspecified and untested) change to how the host software
> learns about the available extruders. The current model (give each
> extruder a different SNAP address, poll the network to see which
> extruders exist, and store the per-extruder info in the preferences
> file on the host) may be slightly inelegant, but it is clear and
> pretty simple to understand. What am not seeing/not understanding
> about your proposal?
>
> Jonathan
>
> _______________________________________________ Developers mailing
> list Developers@reprap.org
> [reprap.org]


--

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

If you want to have some controllable, as opposed to friction locking devices for different extruders you might want to make actuators using nitinol wire rather than the usual much more expensive solenoid actuators approach.

[www.smallparts.com]

Edited 1 time(s). Last edit at 07/23/2007 09:27AM by Forrest Higgs.