changeable print head

"I think the joining one end to another wouldn't be a big problem..."

I don't think that it is a problem of difficulty so much as inconvenience. Right now Tommelise is operating at 2.4 mm/sec head transition speed, which is quite slow compared to the rate that Darwin is expected to achieve. Even at that very slow rate it eats about 300 mm/hour of 3 mm filament. If, for example, you are hand rolling CAPA rods 450 mm long (which, I understand, is about the maximum width that you can achieve rolling CAPA between glass sheets) you are looking at having to weld a new rod on to the end of the old one every hour and a half.

As a practical matter that means that you can't walk off and leave your printer for any significant length of time and it won't operate unattended after hours. Rods, it seems to me are great for tests and probably very practical for materials that you won't use much of like eutectic metal alloys used for printing circuit boards, but not much else.

The utility that I have seen as others have pointed out would be in a cardridge. If you had a cartridge of rods and a mechanism for inserting the new rod as needed, then you could walk away as long as your cartridge didn't empty or you didn't run out of cartridges taking the next step. Those will be improvements down the line maybe, depending on needs. Maybe the soda bottle on a swivel will be good enough I haven't even got far enough to worry about it. But I do think about that kind of stuff.

Hmm, my two cents.

Just to clarify it all for me.

There are a couple of problems here.

1 how to switch heads
2 how to handle material feed
3 how to control specific feed and other parameters per head

I guess that are the three things we are discussing here, right?

1 Switching heads. Issues here are how to do it simply, where to store not used ones and how to keep accurate positioning when you switch.

2 Material feed. Issues here are the fact that you can't carry enough in the head to do the whole job in one go, you want to be able to switch heads without tangling the feeder lines and you have to much variations in feeder methods because of diverse materials.

3 Control specifics. Issues here are where to store specific parameters per head.

I am going to be mulling over point 1 and 2 but for 3 I know how I would like it to be. I would like to be able to have heads with sequential numbers. On the internet there is a database with a collection of parameters for different materials and head types. I select the parameter set that comes closest to my setup and download that into my database and assign it to a head.
With a nice little dialog box I can then tweak the set to get the results I need.

Or am I missing something again?

Lykle

Here's some of my thoughts on your views

Head switching and material feed:

I've put a lot of thought into this one. My personal preference involves a different electrical design than we have, but it should be possible on Darwin. This means that we need to have all heads connected, powered, and talking at startup and nothing drops off the net. While hot plugging is possible, I'm not certain we want to go to the required extents to do proper electrical protection.

A somewhat stiff plastic cable wrap needs to enshroud the power and data lines to each head and be attached to the base of the machine. It may take some trial and error to arrange everything so we don't get crossed lines. If someone wants to attempt a hot-plug slide contact system, you can skip this part.

Continuous feeder units need to have their final feed stage above the unit, probably centered over their storage station.

Rod feeders will probably need to be a skeleton revolver type setup. This can be automatically resupplied at its storage slot via a power feeder. This would be a horizontal bin holding the rods. A rotary gear feeder setup would separate the bottom into invididual stalks and be unloaded by a ramp into a shaft. A simple off-axis beam inside the shaft would send the stalk turning so it would land in the single exposed revolver spot at the bottom. The next empty spot would be rotated into place, and repeat. A powered grasp and drop system could also be used if height was a concern.

A syringe based system would need a revolving tool storage rack to swap syringes. One solenoid to clamp the syringe and one strong enough to push past a pliable storage "finger" set to store or retrieve the syringe would be what was needed for the head (in addition to the feed motor).

Now, to hold each head, in the simplest Darwin system. The heads would be stored just above their operation height on the side rack. I see two solenoids with spring returns on the trolley. One controls the jaws, one raises the jaws. The jaws open wider than they raise. Unpowered position is closed jaws and down. The heads have a mount on the rear. From the jaws perspective, it's a locking dovetail. 90 degrees to the jaws, it's a centering truncated pyramid.

To load a head, the jaws open. The trolley centers on the pickup. The jaws lift (this puts the lower, fixed jaw on the dovetail). The upper jaw closes, and the head puts a little force into it to remove the head. Reversing the process puts the head back.

Head identification:

I personally believe that the heads need to know their own physical attributes (power required, max feed rate, force at feed rate?, special features?, etc) and have a type ID, something perhaps like Lykle's preference. This would allow on-chip checking if the firmware advances. However, material is not the same and needs a separate database on the PC. The RepRap software should be able to cross these two data streams to determine applicable rough data for unknown combinations like actual max feed rate, feed height, etc.

I agree with nophead, there needs to be internal extruder head ID. This does not eliminate the possiblity of "smart" heads, but the minimum starter here is that there needs to be a number with large address space (> uchar!) that holds the extruder head ID, stored in the extruder itself. This number could be unique or non-unique (ie. a production "run" of heads can have the same ID). Xml Mapping files could be distributed with software releases as well as P2P/torrent networks so it is possible to share files which map the extruder head IDs with the ancillary data, such as the extruder's capabilities, statistics, and hardware compatibility.

Hmmm.
I'm no electronics tech., but could you get a readable address using a set of dip switches and a multiplexer?

As I said. I'm no electronics tech. I'm good to remember the resistor code in the morning.

The advantage of "smart" heads to me is that you can create your own modified/hybrid head and program it to just *work* on whatever machine you happened to connect it to. Of course, it's only one more step to provide a separate XML file that contains the head's information, but still, that's slightly less convenient.

once possible route we could take is storing 'defaults' on the PIC. currently, we are not even using the EEPROM on the chip, which is basically its hard drive. i'm not sure if this survives a power-down, but if it does, then it might work.

then, the way i see it working in software is that the host software queries all the connected devices for their types and configurations. the host then loads those configs into its memory. if you change it or something, then it could save the config back to the chip.

that way would probably be the best of both works... the host is ultimately the one in control of all the various parameters, but each device could carry around its own initial parameters in a way that would allow you to attach a device and it would automatically configure.

this is actually probably do-able in the current generation of reprap tech. i'm no firmware programmer, but it seems like it could be done.

I like Zach's approach. It doesn't seem to have a downside. And yes I believe, EEPROM memory can survive a power down, if I know anything about microchips (I've read that back two hardware generations, when it was just PROM, you had to use a UV lamp to reset it... it's much nicer now).

Kyle

EEPROM = Electrically Erasable Read Only Memory

I also agree with Zach here. EEPROM survives power down. The idea he mentioned is actually a good layer of abstraction between the computer system settings and the microcontrollers. (That is , store default extruder head parameters and ancillary data in microcontroller EEPROM). How many extruder head IDs are we expecting to see within the current generation of technology? Probably < UCHAR_MAX ! But in the future, it's probably wise to allow the size of the extruder head IDs to scale up to a 16 bit - 64 bit address space.

Remember it's exponential or bust!

savecore

Well if the firmware for each head is identical it would make sense to put the id in the EEPROM, but if it is different for each type of head, as is quite likely, then it may as well be embedded in the firmware.

---

[www.hydraraptor.blogspot.com]

yup, there could be three levels:

1. hardcoded firmware values
2. semi-hardcoded EEPROM values
3. host controller values.

first it checks host controller. if its not found, it checks the EEPROM, and finally it defaults to the firmware values.

once it finds it, then it sets all the values back up the tree. (eg: doesnt find first 2, pulls from hardcoded. then it sets those values in EEPROM, then also in the host software. if the host software params change, it then saves back to the EEPROM.)

this would probably be a decent approach. the only real way to find out is to actually try it though.

savecore Wrote:
-------------------------------------------------------
> How
> many extruder head IDs are we expecting to see
> within the current generation of technology?
> Probably < UCHAR_MAX ! But in the future, it's
> probably wise to allow the size of the extruder
> head IDs to scale up to a 16 bit - 64 bit address
> space.
>
> Remember it's exponential or bust!
>
> savecore


As I understand Zach's scheme, it doesn't include a central registry of head IDs, which was one of the advantages in my opinion. I don't think it's realistic to keep a listing of all the heads that exist on some central Omnipotent Server, and dish out the parameters for each from that. That might make sense if there was a relatively finite number of head types and each was expected to have many identical copies. But in an open-source, community driven model people are bound to be modifying and experimenting with different head types all the time. Two that might have started the same could slowly diverge until they were completely incompatible.

To me, it makes much more sense to let the head's creator/duplicator set the right values for his own hardware and not have to worry about updating it for others. If you're going to print off, assemble and sell 100,000 copies of your super-ultimate-ownz-all-printing-head, just preload all of them with the correct default values onboard, and then ship them off. No central registry needed, and if people want to modify them they can go ahead and change those values for their own equipment as necessary.

ZachHoeken Wrote:
-------------------------------------------------------
> yup, there could be three levels:
>
> 1. hardcoded firmware values
> 2. semi-hardcoded EEPROM values
> 3. host controller values.
>
> first it checks host controller. if its not
> found, it checks the EEPROM, and finally it
> defaults to the firmware values.
>
> once it finds it, then it sets all the values back
> up the tree. (eg: doesnt find first 2, pulls from
> hardcoded. then it sets those values in EEPROM,
> then also in the host software. if the host
> software params change, it then saves back to the
> EEPROM.)


What is the purpose of even bothering to store the values in the host software, beyond trying to avoid EEPROM read cycles? Quick calculation: assuming you switch back and forth between two heads every 10 minutes 24 hours a day, 7 days a week, and assuming you have 300,000 read cycles before your EEPROM goes bad, it would still take 11 years before the EEPROM expired. I can understand that during a certain print job it would make sense to hold the values locally. But why not just have it detect them again from EEPROM each time the head was plugged in? It seems to me that if you try to store the values locally you're back into trying to create a registry of all heads, because otherwise how are you going to verify that the one that you just detected is the same one you have the local settings saved for?

>
> What is the purpose of even bothering to store the
> values in the host software, beyond trying to
> avoid EEPROM read cycles? Quick calculation:
> assuming you switch back and forth between two
> heads every 10 minutes 24 hours a day, 7 days a
> week, and assuming you have 300,000 read cycles
> before your EEPROM goes bad, it would still take
> 11 years before the EEPROM expired. I can
> understand that during a certain print job it
> would make sense to hold the values locally. But
> why not just have it detect them again from EEPROM
> each time the head was plugged in? It seems to me
> that if you try to store the values locally you're
> back into trying to create a registry of all
> heads, because otherwise how are you going to
> verify that the one that you just detected is the
> same one you have the local settings saved for?

well, you need to load them into the host software at some point in time for it to print. the host software is the one that takes the values like extruder speed / etc and figures out when and where to move the print head. it also is your interface for changing those values. it definitely needs to be in the loop here.

ZachHoeken Wrote:
-------------------------------------------------------
> > I can
> > understand that during a certain print job it
> > would make sense to hold the values locally.

> well, you need to load them into the host software
> at some point in time for it to print. the host
> software is the one that takes the values like
> extruder speed / etc and figures out when and
> where to move the print head. it also is your
> interface for changing those values. it
> definitely needs to be in the loop here.


Right, I understand that and that's what I meant when I said "I can understand that during a certain print job it would make sense to hold the values locally," I'm sorry that my statement was unclear. But from what I understand you're proposing that a value stored indefinitely in the host software would take precedence over a value stored in EEPROM, and that's what doesn't make sense to me. Is that not what you meant?

no, i'm saying that it would generally be stored in the EEPROM, unless changed in the host software (which would trigger an EEPROM rewrite)

you would just want to read in the values from eeprom once at the beginning when you start up the host program. then you store them locally for whatever host stuff you need to do.

we're basically agreeing here.

Zach,

Hmm. If you have it automatically throw client side settings to the firmware, then you could end up, eventually, with a reprap somewhere that someone screwed up so that it consistently corrupts a certain extruder model.
And if you then drop a corrupted extruder onto a clean reprap, it'd load in the corrupted settings as the default.

You might want at least a dialog box to offer to upload/download settings.


Kyle,

I agree. Putting all the information for all heads in one spot can cause trouble. If the servers go down, (or move.) If someone manages to convince some government somewhere to impose protectionist practices, (hey, you can make WEAPONS with those things,) if everyone and his brother cooks up a slight varient on the same basic head code, if some hacker decides on some mischief, and chooses to attack the central servers, if two guys check the registry for available numbers, and submit radically different specs tied to the same number, to different servers, before the two daughter servers check home with the mother server, or otherwise cross-pollinate their lists, if some guy gets all the parts for a reprap, including the heads, but forgets to download the settings before disappearing back into the wilderness where he needs it...

Better to have the information travel with the heads, if possible.

Roach_S Wrote:
-------------------------------------------------------
> Zach,
>
> Hmm. If you have it automatically throw client
> side settings to the firmware, then you could end
> up, eventually, with a reprap somewhere that
> someone screwed up so that it consistently
> corrupts a certain extruder model.
> And if you then drop a corrupted extruder onto a
> clean reprap, it'd load in the corrupted settings
> as the default.

When I read his post it seemed to me that that is what he was proposing as well, and I had the same objection you do. As far as I can tell from his subsequent posts, however, when he said that the software looks first to settings stored client-side, he intended for said client-side settings to be loaded every time a head was plugged in, and, presumably, unloaded when the head was removed. The client-side software only writes its values to the EEPROM when you change those values client-side.

So it sounds to me like we're all arguing for the same thing.

Kyle

> So it sounds to me like we're all arguing for the same thing. smiling smiley

yup. to rephrase again (and this is all a theoretical plan), you plug a head into the machine, the host software recognizes it, queries the board for its settings (which can come from firmware if its the first time, or eeprom if contains them.) if the settings for that specific head change, the host software writes them back to the eeprom. if something goes wrong (eg. corruped settings) the host can simply reload the firmware settings.

i decided not to go into UI specifics (dialog boxes) because thats more polish than how the system operates.

ya grok?

Yes.