Beyond the Sanguino

I'm just wondering what stopped Zach at RRRF from using a larger chip (than the ATmega644P).

There are a lot more options that have more pins and memory, etc. The biggest one is the ATmega2560 with 100 pins (86 max I/O pins), and a bunch more of the other stuff (see [www.atmel.com] for a list of the various chips).

It is $17.97/unit at Mouser, though, so perhaps not that one specifically, but the ATmega640 is the same thing with less Flash, EEPROM, and SRAM for $11.80 (which makes it more comparable to the ATmega644P, which is around $6-$8).

I think the only downsides are that it would be TQFP, not PDIP, and that the max frequency (and thus max instruction rate) is 16MHz instead of 20MHz. I'm betting it's the packaging options (or lack there of) that stopped Zach, as he says:

Quote

Why not use the Wiring board?
The wiring board is SMT only, and no DIP version of the atmega128 exists.

[sanguino.cc] at the bottom.

However, I don't think this is a good enough reason. In fact, it may be better that it's not PDIP, as the board can be much smaller with the SMD's.
It would be a great way to encourage the development of a RepRap pick-and-place/soldering head, as well (so we can automatically solder it). It isn't necessary, though, as we are using SMD's elsewhere and just soldering by hand (specifically, the magnetic encoder chip and the usb-to-serial chip on the breadboard Arduino, which is what I was going to be using until I couldn't get it to work and gave up).

---

So that's that about the bigger chip. I also have a few questions about the use of multiple chips. If we wanted to wire up multiple ATmegas (like, say, multiple ATmega168s or your old ATmega168 and your new Sanguino and your brand new ATmega2560), how exactly would that work?

Would we wire up the main chip, as in the traditional Arduino, to the USB stuff, etc, and then connect the TX/RX and 2 I/O's on the next chip to 4 I/O's on the main chip? And then program the second chip using the 2 main chip's I/O's connected to the TX/RX, and then trade data based on programming between the I/O-I/O connections?

Or could we just use 2 pins on each, the two I/O's on the main and TX/RX on the secondary, and then use the TX/RX for data after programming (I don't know if this is possible)? Or if that wouldn't work, what about 3 pins on each chip: TX to I/O, RX to I/O, and then an I/O on each which sends data two ways (possible?)? If that wouldn't work, could we reduce it to 3 pins on the secondary and 2 on the primary, by having the 3rd pin on the secondary switch the connections between I/O-TX and I/O-RX to I/O-I/O and I/O-I/O and back? Or do you need to communicate with TX/RX normally?

It should be obvious that I know little about the ATmega chips and Arduino at the moment. I'm just jotting down ideas; I'll take the time to actually learn about and understand the specifics later. It should also be noted that I don't quite understand how a bus is implemented, and I don't quite know how that applies here.

---

There really was a third thing I was going to say, and I think it was semi-important, but I can't remember it... and I am falling asleep now (I wasn't before I posted; that's sad)... so oh well.

Zach originally convinced the Reprap team to shift from the SDCC Pic 16F628A rig to Arduino because the Arduino development community had a stable compiler, which SDCC was most definitely NOT.

The problem with the move was that it solved the compiler problem we were having but didn't solve the problem of the CPU not having sufficient resources to really allow Reprap developers elbow room to try new stuff. Zach obviously realised that and has tried to leverage the Arduino compiler to work on the AtMel644P which is richer in both pins and resources than the dinky microcontrollers used by the Arduino crowd.

Zach has tried very hard to stick with the "open source" dictum of the Reprap project vis a vis the compiler for firmware. When you take that dictum seriously (I don't) the migration from the old Pic16F628A/SDCC system to Arduino to Sanguino makes perfect sense.

The very serious downside of that, however, is that the Reprap project faces the prospect of changing it's controller boards three times in maybe 18 months if Zach talks the team into switching to Sanguino in the near future.

I blew off 16F628A/SDCC some time before Zach discovered the Arduino open source community. Instead of going open source I found the very inexpensive Oshonsoft Basic compiler which was rock solid reliable and trivial to learn. From the 16F628A, I migrated to the 40 pin 16F877A and, when I found out that the 16F family of chips didn't have an overflow flag for interrupts and a stupidly short interrupt stack I migrated to the pin-compatible 18F6510. If you compare data sheets you'll find that the 16F6510 and the AtMel644P are almost identical in performance and characteristics.

I would have stayed with that save that I discovered that I really had no use for about half of the 64K flash memory on the 6510 and really wished that I had a native capability to support USB on-chip.

When I retired Tommelise 1.0 just over a year ago, I shifted from the 18F6510 to the more or less pin compatable 18F4550, which has native USB capability. That shift let me get rid of the whole Max232/serial conversion components that convert serial comms as Pic and Atmel understand it.

Like yourself, I am afraid that Zach will very quickly discover that his 40 pin AtMel644P is again insufficient.

The reason for that is that while both the Darwin and the Tommelise 2.0 position robots have matured and are unlikely to require a lot more cpu power or pins the extruder has really taken off in development in the past 4-6 months which has resulted in its requiring things like a solenoid-driven shutoff valve and a rotary encoder. I could just about support my variation on the old Mk II extruder AND the positioning robot of Tommelise with 40 pins. The moment the Reprap team started "improving" it, however, I knew that I was going to have to either get more pins and computing power on the controller board or dedicate a second controller board just for the extruder.

For the moment, I've taken the second route and am looking at having two 18F4550 boards, one for the positioning robot and one for the extruder linked with an I2C comms line. That gets me enough pins and computing power to run Tommelise 2.0.

Just a few days ago, I found, however, that my Oshonsoft Basic compiler in its present version doesn't have the ability to run an I2C link between Pic's with one in the Master mode and the other in slave. I shifted to the Mikroelektronika Basic compiler last weekend when I found that they had code examples which could do the job in their C compiler. I am, at this moment, rewriting the C code into Basic.

The big problem that I am facing with 40 pin Pics, which I have no doubt is even a more serious problem with 40 pin ATMel chips is the restricted range of comms pins (SPI, I2C and the like). The 18F4550 has a single module which lets you do EITHER SPI OR I2C but not both at the same time. That is a major pain. While I can do board to board coms AND run my EEPROM print buffer off of the same I2C bus I can't add in a SD card reader even if I throw away the EEPROM buffer because the SD card reader requires SPI alone.

Getting that sort of flexibility puts me beyond the capacities of 40 pin Pics. If I make a conservative jump I'll probably go with the Pic 18F87J50...

[ww1.microchip.com]

That gives me two comms modules which will allow me to run I2C and SPI at the same time. It's a lot more powerful than the ATMel one you suggested and costs less than US$5 in one-off quantities.

If I bite the bullet and decide to go for surface mount, however, I'll probably make the jump to a 16 or 32 bit Pic. They don't cost any more and they are incredibly more powerful and resource rich.

Edited 5 time(s). Last edit at 08/26/2008 11:09AM by Forrest Higgs.

> I think the only downsides are that it would be TQFP, not PDIP, and that the max
> frequency (and thus max instruction rate) is 16MHz instead of 20MHz. I'm betting
> it's the packaging options (or lack there of) that stopped Zach, as he says:

I can teach my girlfriend how to solder a through-hole chip in about 10 minutes. Can you?

I cant solder a TQFP package, not talking about the replacement. I fied 3 microcontroller in the last month. With a pdip package its just a replacement (no soldering) with smd, I dont know how to desolder the smd chip.

Quote

So that's that about the bigger chip. I also have a few questions about the use of multiple chips. If we wanted to wire up multiple ATmegas (like, say, multiple ATmega168s or your old ATmega168 and your new Sanguino and your brand new ATmega2560), how exactly would that work?

The apparently short-lived dual arduino setup used a powercomms board from the gen 1 electronics to link the host PC and two arduinos. Given that the firmware has already implemented the SNAP network protocol, it would seem to be a sensible first choice... especially as the dual arduino setup at least proved the concept even if it was quick abandoned.

The atmega644 also supports I2C and SPI. SPI always looked good, but it does require one IO line on the master controller per slave controller, I do believe.

None of these approaches really scale conveniently, as you need a network hub with sufficient resources to connect to all the various boards in the system. Bus based networking protocols might be better but they would of course require additional hardware... a dedicated networking chip wired to the controller's SPI pins, for example. Extra expense and hassle, certainly. Possibly SMT work to be done, which might be good to avoid. CAN bus is one I looked at which seems quite appropriate for this job, though implementing your own on a CPLD or whatever requires a license from Bosch, which is less good. Open protocols are to be preferred where possible, I think

My main interest in the scaling is that I see each toolhead having its own controller board. This frees the main controller from having to deal with any of the complexities of individual toolheads, ie quadrature RPM sensing for speed control, ADC stuff for temperature reading, nozzle valve control It can concentrate purely on moving the toolhead around and passing toolhead-specific instructions to whichever head(s) is (are) attached at the time.

'Idle' heads need not necessarily be totally disconnected, and indeed in some situations you wouldn't want them to be. Keeping heated extrusion heads warm whilst they're not in use would prevent the build having to pause every time the extruder was reattached and warmed up before printing could begin again.

I think having a bunch of relatively small and dumb peripherals which can easily be chopped and changed is better than having a couple of huge and powerful processors, which in turn require huge and complex firmwares. The more complex that gets, thet harder it is going to be to debug things when it inevitably goes wrong.

Along with the I2C and SPI interfaces, there is also the Dallas (now Maxim) 1-wire which is used extensively in home automation and alarm systems and thus there are many sensors available off the shelf, and even solenoids and motors (or rather interfaces to them). The end of the one wire needs to be terminated properly, but you only need one port on the processor to drive the whole "network" of sensors/drivers. There is also a set of chips which are designed to connect to the bus, and the software to drive the line is well defined and in the open - both for bit-banging designs and for processors with the interface built in.

For more reliable stuff there is also CAN which is designed for Vehicles. But that is probably overkill.

Quote

CAN which is designed for Vehicles. But that is probably overkill.

My interest in CAN is that as it is a bus-based network, adding additional devices is not terribly difficult. All the alternatives require one more more additional IO lines per attached device.

Ru: For CAN support there is specialised microcontrollers (I know for sure, that mirochip produces pics with built-in CAN support).

Sooner or later we will need a bus, but I think rs-485/232 would make much more sense. It makes more sense because sanguino has already two hardware UART! So one can be used to communicate with the host pc and the other one can be used as a bus master.

I think we should implement rs-232 based bus, and after we could migrate to rs485, if (and only if) there is noise issues as with the i2c interface was.
(the pic based gen 1 electronics used i2c between pics)
I2C is noise sensitive, rs232 is much more less, and rs485 is the best option.
Migrating between rs232 and rs485 is as simple as replacing the interface chip.

The CAN interface is better because the bus protocol and error handling is implemented in hardware (if Im correct).
But there are limited microcontrollers which handles it, these microcontrollers are rare (hard to buy), and more expensives.

And the devices which support CAN protocol are more expensives too.

Khiraly

khiraly1 Wrote:
-------------------------------------------------------
>
> (the pic based gen 1 electronics used i2c between
> pics)
>

I'm pretty sure that you are mistaken about that. The 16F628A doesn't support hardware I2C comms. Simon used an RS232 daisy chain in that.

>
> I2C is noise sensitive, rs232 is much more less,
> and rs485 is the best option.
> Migrating between rs232 and rs485 is as simple as
> replacing the interface chip.
>

Yup, as long as you stay with the Arduino open source community you are pretty much stuck with using 8 bit ATMel controllers. That pretty much dictates and severely limits your technological options.

Quote

Ru: For CAN support there is specialised microcontrollers (I know for sure, that mirochip produces pics with built-in CAN support).

It would be preferable not to have to use extra ICs, especially if they have to be SMT ones. I've not stopped to look to see if this is the case, but it seems likely

There are plenty of things with CAN support out there. One small beef I have with the protocol is that it is patented, and hardware implementations must be licensed. This would prevent you from using a CAN soft core in a CPLD or an FPGA, for example.

Seem a bit far fetched to be considering these sorts of things? Small CPLDs are very cheap, and quite capable of doing sophisticated tasks (like stepper motor phase generation) at speed. You get quite a lot of programmable logic for the price of, say, an L297. A single chip that could be sent the instruction "go n steps forward" and handle everything else (like accelleration ramping, or whatever) would make various bits of firmware design much easier, and would be a very useful little toy for other projects.

Quote

the pic based gen 1 electronics used i2c between pics

It was just a plain old UART with RS232, but the SNAP protocol was implemented on top of it in software, I believe. It was easy because the host PC could already speak RS232 via the serial port, and SNAP could be implemented in the host software. Which it was.

Quote

I think we should implement rs-232 based bus, and after we could migrate to rs485

This lets you daisy-chain boards, sure. This isn't necessarily a good configuration when the number of attached boards rises, as boards near the controller would have to waste cycles passing messages not intended for them back and forth.

Quote

Yup, as long as you stay with the Arduino open source community you are pretty much stuck with using 8 bit ATMel controllers

The suggestion here was to use an external IC, which could be attached to any uC. Even a PIC Sure, it might use up your SPI lines, but with a suitable networking protocol there's nothing to stop you communicating to other devices attached to the network that could control, say, SD cards.

The problem there becomes the hassle and expense of extra ICs, as I mentioned above.

Ru, you say that "All the alternatives require one more more additional IO lines per attached device." This is not the case for Dallas 1-wire, all the attached devices hang off a single wire (plus ground), that wire even provides power - but only enough to power the interface chip, not to power things like motors. So one interface pin controls the entire network of sensors and driver.

Quote

all the attached devices hang off a single wire

Well, that'll teach me to relay on my somewhat imperfect memory rather than having a quick peek at wikipedia or whatever.

It certainly looks interesting now, though it would require the microcontroller for each slave device to implement some sort of useful networking protocol; something that the CAN interfaces already have.

I also have no idea what sort of bandwith requirements a future reprap might need. 1-wire is not an enormously high-performance bus after all, but it may well be that we don't need such a thing. Tricky.

The chips that Dallas produce already have the protocol built into them. There is no local microcontroller per device. Yes we would need to understand the bandwidth, but I do not think that this is going to be a problem at least with current designs.

Quote

The chips that Dallas produce already have the protocol built into them.

A network protocol stack has many layers. 1-wire provides a physical layer, and a data-link layer (as it provides per-device addresses) but that's all. It is quite minimal, which is good for various reasons, but it doesn't do everything for you (as far as I can tell, feel free to correct me if I am wrong!)

The key thing is that it would appear to allow some error detection via a CRC code appended to each transmission, but it would appear that responding to an error detection correctly is up to the engineer. Therefore, a higher level protocol is required to attempt retransmits, or eventually give up and raise the communications problem higher up (ie, to the host software, or whatever).

This sort of logic does require a uC to hold state and make decisions, not just a relatively dumb network interface. It is also possible that the simple error detection scheme is not sufficient for some tasks that might involve bulk data transfer, and might require additional levels of error detection at higher levels.

The fact that 1-wire doesn't use differential signalling (as RS485 does) and so is going to be somewhat vulnerable to external noise sources (say, a bunch of motors) does concern me somewhat. I don't know if anyone here has experimented with I2C between boards in this sort of environment, or how the old PIC based electronics coped with whatever they were doing, so possibly I'm unnecessarily worried about this

> I'm pretty sure that you are mistaken about that. The 16F628A doesn't support
> hardware I2C comms. Simon used an RS232 daisy chain in that.

Thank you for the correction. I've read "something" about i2c used in reprap, but Im now sure that I read in nophead's blog...

I have found the relevant blog:
[hydraraptor.blogspot.com]

"A tough challenge then to make I

From that page, it looks like the solution was a few (nice, admittedly) caps, and some ferrite beads. That doesn't seem like too much to me. Alternately, if we swap to brushless motors instead of DC motors, then we don't have (unintended) spark gaps and high-voltage transformers as part of our motors; just relatively simple-to-handle inductors. It'd probably take a bit more care to make them run /really/ clean, but it's doable once the motor doesn't inherently charge an inductor up high and then try to stop current from flowing through it. When current is the integral of voltage you don't really want to try to make the current become zero instantaneously

He did say it was also interfering with the television downstairs, which suggests that it's just dumping way too much noise out. It's probably preferable to cut down on the noise in the system instead of just beefing up the device until it can run.

I2C is really a rather nice little protocol - two lines, send an address and whether you want to read or write, and then data to that address. No CRC, but place where you could put one, and acknowledge bits after every byte (if I'm remembering right). And lots of microcontrollers (and computers, by the way - I'd be nervous, but the system management bus is a tighter-tolerance version of I2C. Perhaps optoisolated.) already talk it.

Quote

Btw CAN have a non-negligible license-fees.

Only if you're making a hardware implementation. By purchasing a CAN-capable IC, you are buying the capability from a manufacturer who has licensed the protocol from Bosch. You don't have to pay any more.

You do have to pay if you make your own implementation in a CPLD or FPGA though, which is something I am interested in using in the future.

Quote

I know a bit the CAN protocol (learned back in university), just cant justify why is it needed here. What features is REALLY needed?

RS485 is just the physical part of a networking stack. Someone is going to have to implement some kind of link-layer on top of it. You just listed a bunch, some of which use RS485 as their physical layer. Ethernet (for example) doesn't specify a physical layer.

CAN bus is one possible link-layer protocol. It is of interest because it is quite a powerful one, and CAN-capable microcontrollers and other handy interface chips exist, saving us from the need to find or build networking firmware. Ethernet is another that might be interesting for the same reason, though given the sort of tasks that CAN was designed for, it might be more appropriate for our use than ethernet.

The arduino SNAP firmware and the gen 1 PIC electronics use the SNAP protocol implemented in firmware over RS232 signals. SNAP looks like a quite useful little tool, but it does require that firmware support.

If I2C will do the job though, we may as well use that I do see quite a few instances of people having problems with its sensitivity to noise, and it would be nice to have a more robust (and dare I say it, idiot proof) system. But if that 'better' system involves enough extra hassle and expense, it probably isn't worth it.

Not sure if this is what you guys are looking for but i cam accross this kit.

CAN Node
New CAN Node, will work on most CAN systems. Provides 3 digital inputs and 2 digital outputs, together with 2 analog 8-bit inputs. Up to 64 units allowed on the one bus. Each unit address can be easily programmed on the bus. A set of commands is preconfigured for turn output on and off, together with reading of the various inputs. Unit will also respond to group commands, such as a system wide shutdown. Kit comes complete with programmed PIC and CAN interface IC. Detailed instruction are also included.

Features

Dan you may be my hero, im going to look into that.

Im building my own reprap at the moment, only building physical at the moment though. But ive worked with CAN a fair bit and they sell alot of encoders for the can. The problem so far has been getting it to work with the motors and the extruder.

your link may prove usefull in this respect. The main benifit for me with a CAN is that i can add stuff as much as i want and also i can do more computing on the PC . so even if bits cost more i'll save money on the controller hardware. ITs pretty easy to get a can to usb lead for the pc. and on the CAN you can get pretty high baudrates. So its shifting alot across.

main thing is controlling the motors and heaters etc. for a resonable price.

Oh and CAN is in CANOPEN but CAN OPEN is not in CAN. its just a higher level protocol stack. not that important for what were doing.

Also making a master for the can open is easy.

noz

I believe Zach went with that particular device because it was as big IO wise as he could go and still have through hole capability. I believe that beyond this devices capabilities all the packages are SM of some variety or other.

Some variants of QFP are solder able by hand but only for the skilled, tooled up and patient.

Through Hole PCB's and construction are within reach of most folk.

A lot of folk though struggle with Surface Mount (SM).

However as SM is optimized for machine assembly, SM should be the way to go eventually for the RepRap project if we want machines that can assemble themselves.

But only if we have made machines that can can make machines and do it for us.

I guess we need to boot strap a machine capable of doing this first though even if only as entry level, it needs "assemble by people at home" levels of technology.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> I believe Zach went with that particular device
> because it was as big IO wise as he could go and
> still have through hole capability.
>
Zach may disagree, but from where I stand it looked to me like Zach promoted Arduino because it had a solid firmware compiler, something that Reprap didn't really have with the SDCC open source compiler that it was using before.
>
> I believe that
> beyond this devices capabilities all the packages
> are SM of some variety or other.

Yes, they are, sadly. In that way Arduino is a total dead end insofar as scalability is concerned because really, you can't provide a lot more capability with 40 DIP pins and 40 DIP pins is the largest DIP package readily available.

Even with the Pic 18F4550 that I use which is also 40 pins, each of the pins has 3-4 potential functions.

Forest I think we are heatedly agreeing with the first.

That was probably a driver in the go arduino process, (I don't know I wasn't a party to the discussion or decisions) I was actually referring to the choice of device for the sanguino.....

I offered Zach a route through using FPGA's to leverage pin counts with the Arduino using a slave fpga for clever IO. I guess this would leverage the processing power too if more was done in hardware and required less processing.

I recall zach was'nt keen citing Through Hole preference and explained that this was the driver in choosing the sanguino processor.

Whilst I personally don't agree entirely with the stand point I can understand the benefits to keeping the electronics assemble able by anyone with a soldering iron.

Certainly at least for now.

Through Hole mounting packaging is certainly dwindling though and I guess we need to look to "what next" at some point.

As a concept and as useable Open Source material the Arduino is quite impressive. Adopting it as a building block towards the RepRap is certainly an adaptation of "Standing on the shoulders of giants" to quote Linus Torvalds autobiography.

Not everyone is clever at electronic design and not everyone is clever at embedded systems development. Fewer still can hack assembler and write for programmable logic. Although given current trends there is certainly increasing pressure on developers to move the programmable logic route.

So as a quick and easy route into it I can see the appeal of the Arduino.

I personally would not have chosen any of the Atmel Micros. This is a personal choice. I actually don't much like the PIC devices even though I do work with them and have the development kit from Microchip (ICD, C Compiler etc). Their is certainly a cost and ubiquity incentive to their usage.

The Hitachi H8 and H32 range were my favorite micro controllers but were certainly not that cheap.

Favorite Processor had to be and still is (I still have some lying around somewhere) the Inmos Transputer.

All in all the sanguino is quite a clever dodge, upgrade the hardware and keep software compatibility. Certainly preserves the investment and allows the RepRap project to use software developed for other purposes on the same platform.

Where next is the question.......


Hope this helps

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The way I'm going is to distribute computing power via slaved I2C Pics which answer to a central controller. Tight now I'm using two 18F4550's with the positioning robot talking to the PC and controlling the extruder via an slaved I2C link.

Quote

"Standing on the shoulders of giants" to quote Linus Torvalds autobiography.

That particular quote is a Newton one.

If I have seen farther it is by standing on the shoulders of Giants

Much as Torvalds has done for us, being an arrogant OS kernel engineer isn't quite on a par with what we got from Newton

Quote

Through Hole mounting packaging is certainly dwindling though and I guess we need to look to "what next" at some point.

Hopefully by that point there will be a sufficient manufacturing base to at least create breakout boards for surface mount ICs at a sensible price and with wide availability.

I think we still have a few years left to worry about that, and for reprap at least the solution to the problem will arise naturally as the project evolves.

So if Mr home constructor cannot construct his own breakout boards then the means of production are again removed from him and you are back to square 1 pre RepRap.

Why then bother with a RepRap you can construct at home.

Unless your objective is to support the project only until your actions bring down the price of commercial machinery to inkjet price levels ???

tsk tsk tsk

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

So if Mr home constructor cannot construct his own breakout boards then the means of production are again removed from him and you are back to square 1 pre RepRap.

Then he can obtain them elsewhere, as we already have to do with large chunks of the reprap.

People are already quite happy to purchase arduinos after all.

I'm currently using the Tommelise 2.0 positioning robot to mill the parts for its own extruder including the reducing gears and a much tighter z-axis slide.

When the cutters and blank PCBs arrive next week, I'll be able to mill PCBs for next-generation Tommelises as well.

I've got a prototype design for a linear stepper motor that Tommelise will be able to build as well.

I don't think that anything that I am doing with Tommelise is impossible to do with a Darwin. Right now, however, the mainstream Reprap development team are dealing with a rather different set of priorities.

I haven't figured out how to cut lead screws and thrust collars yet, but I figure that it's only a matter of time.

Buy it :-
[tinker.it]

Build it :-
[www.arduino.cc]

You have a choice.

You might find that some folk object to that choice being taken away from them.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

You might find that some folk object to that choice being taken away from them.

Quote

Through Hole mounting packaging is certainly dwindling though and I guess we need to look to "what next" at some point.

So, surface mount isn't an option. Through hole isn't an option.

You have a plan C?

Doing surface mount yourself is not impossible, in the same way that building your own extrusion head or cartesian bot isn't impossible. Currently it is expensive and difficult to obtain suitable parts to throw together a darwin without having to engineer it all yourself.

It is assumed that in time extruded parts will become much easier to obtain and much cheaper, as the number of working and replicating repraps increases. I see absolutely no reason why surface mount electronics should not become widely available once the reprap is capable of doing isolation milling and pick and place, providing electronics at the same rate and with the same ease of availability as the extruded parts.

I like it when other folk understand plan C without needing it explaining.

Indeed we agree.

Surface mount does indeed become accessible via a suitably tooled up Darwin plus maybe one or two extras. Extras that again should be within the reach of home construction. Either directly (you build it) or indirectly (you build something, that builds it)

Extras :-

A simple reflow oven, very much doable and can be made out of cheap domestic parts, something like an arduino or microcontroler of your choice to give burst firing or phase angle temperature control (heat up/cool down slopes etc).

I guess you could also construct a hot air blow gun and nozzle Tool Head to reflow in situ on the Darwin....

Items that are not strictly necessary but perhaps become so if you want machines to completely assemble themselves.

Pick and place pen.

Solder paste dispenser pen.

A big question is do you actually really need milling capability or only hole drilling (via's) ??

Interestingly enough if you have a reflow oven and can protptype boards, you could probably dispense solder paste. (Manual paste dispenser pen ?) and pick/place (Manual Pick and place pen ?)

Why wait for dispensable metal tracks ??

Thoughts for what they are worth.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Ru Wrote:
-------------------------------------------------------
>
> It is assumed that in time extruded parts will
> become much easier to obtain and much cheaper, as
> the number of working and replicating repraps
> increases.
>
I expect milled parts will be cheaper for a Reprap to create until we have our own filament extruder and recycled plastics grinder going.
>
> I see absolutely no reason why surface
> mount electronics should not become widely
> available once the reprap is capable of doing
> isolation milling and pick and place, providing
> electronics at the same rate and with the same
> ease of availability as the extruded parts.
>
No doubt, the question, however, is how we get from here to there.