Reprap Electronics Devolpment

Hehe

I like:-

"evaporate, like the morning dew under the gentle caress of a blowtorch."

That is just so evocative.

I think we are agreeing to death that there is definitely mileage and room in the project for an ARM based control board.

There are perhaps more reasons in favour than against.

The argument of USB v Ethernet has no mileage in it. Being simply a preference. Its like trousers or shorts. Easiest fix to the argument is design in both (although this does potentialy increase the price).

Their is a connector specification and board format ready to go in the BEEF section of the wiki (or do your own). [reprap.org]

(Speaking of which, Sebastien how are we doing with a repository for the source tree for this)

If you want the kicad source files PM or email me and I will send you the current state of play until we have a repository for it.

So who is going to do an ARMduino or two.... That can be programmed via the Arduino IDE, or a branch thereof. (optionally you can always use the commercial tools and tool chain if you want, if a JTAG/ICSP port has been designed onto the board).

Please do WIKI pages or add to existing wiki pages whichever way you go........

---

Necessity hopefully becomes the absentee parent of successfully invented children.

(Speaking of which, Sebastien how are we doing with a repository for the source tree for this)

I've been distracted by politics.

But I'm working on it.

---

-Sebastien, RepRap.org library gnome.

---

Remember, you're all RepRap developers (once you've joined the super-secret developer mailing list), and the wiki, RepRap.org, [reprap.org] is for everyone and everything!

I'm interested in working on an ARM based design as a collaborative effort.

I'm an Electrical Engineer actively involved embedded ARM development and am very comfortable with the type of electronics in Mendel.

I'd be happy to help in anyway I can.

TC

I'm in TC, i'm an Embedded Software engineer so we have two bases covered.

Shall we setup a working group?

annodomini2 Wrote:
-------------------------------------------------------
> I'm in TC, i'm an Embedded Software engineer so we
> have two bases covered.
>
> Shall we setup a working group?

I would also prefer ARM but right now I am building my RepRap so I don't know if I have free time to help.

I am being looking for cheap ARM boards and this one looks good (25€): [shop.ngxtechnologies.com]



If 32kbytes flash code is enough, then I think we should go with LPC1343 boards that cost about 13€.

Edited 1 time(s). Last edit at 04/02/2010 07:10PM by casainho.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I've nothing against the LPC1343, I have an LPCxpresso version, but the lack of PWM makes it less suitable for a complete system.

annodomini2 Wrote:
-------------------------------------------------------
> I've nothing against the LPC1343, I have an
> LPCxpresso version, but the lack of PWM makes it
> less suitable for a complete system.

I forgot that. My idea is to find a cheap one.

But PWM is just used for extruder heater, no? -- and I think PWM frequency for extruder heater can be of slow frequency... and if Ardunio @ 16MHz can do it, than this ARM @ 72MHz can for sure also do it :-)

The next LPC is LPC175x, with: "The peripheral complement of the LPC1759/58/56/54/52/51 includes up to 512 kB of flash memory, up to 64 kB of data memory, Ethernet MAC, USB Device/Host/OTG interface, 8-channel general purpose DMA controller, 4 UARTs, 2 CAN channels, 2 SSP controllers, SPI interface, 2 I²C-bus interfaces, 2-input plus 2-output I²S-bus interface, 6 channel 12-bit ADC, 10-bit DAC, motor control PWM, Quadrature Encoder interface, 4 general purpose timers, 6-output general purpose PWM, ultra-low power Real-Time Clock (RTC) with separate battery supply, and up to 52 general purpose I/O pins."

Maybe Ethernet and CAN are important? -- the idea is to continue to keep a secondary board for extruder or not?

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

annodomini2 Wrote:
-------------------------------------------------------
> I'm in TC, i'm an Embedded Software engineer so we
> have two bases covered.
>
> Shall we setup a working group?


I'm happy to see the interest in a collaborative ARM development.

I think a new group would be best since there will be many aspects to the development that would then be topics under that group. Does anyone know how to get a new group started?

TC

I know this topic isn't too active at the moment but I was interested enough to read it through top to bottom. One thing that isn't clear to me is the "shield" concept. Can someone point me at a description, drawing, or picture that would clue me in (as I'm clueless at the moment).

Thanks!

TC

One thing that isn't clear to me is the "shield" concept.
Google "Arduino Shield".

---

-Sebastien, RepRap.org library gnome.

---

Remember, you're all RepRap developers (once you've joined the super-secret developer mailing list), and the wiki, RepRap.org, [reprap.org] is for everyone and everything!

I think we should first discuss what we need from moving the actual 2 arduino boards (main + extruder) to any other system. At the same time I think we should maintain a wiki page with that reasons.

One point I think is needed to get better is the price, electronics are expensive and difficult to source. I am not sure we need 2 different boards, the main and the extruder, one would be cheaper. Since Mendel is stable now, I would prefer to buy only one board + stepper motor drivers.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Might be best to setup a group and take it off this thread and/or forum.

There are a number of practicality, cost and technical issues that would need to be covered.

As the old saying goes, 'there's many ways to skin a cat'

Don't forget the "working group" logo.

---

-Sebastien, RepRap.org library gnome.

---

Remember, you're all RepRap developers (once you've joined the super-secret developer mailing list), and the wiki, RepRap.org, [reprap.org] is for everyone and everything!

On PWM

Don't get hung up on a lack of dedicated hardware PWM it is trivial to do in software particularly for the requiremnt/s of driving a heated bed and an extruder heater.

The thermal response of both of these items means arelatively low PWM frequency is plenty good enough. I think Nophead would perhaps argue that On/Off control is suficient.

A timer and interupt is enough.

I usualy discard micro-controlers for having poor A to D.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> On PWM
>
> Don't get hung up on a lack of dedicated hardware
> PWM it is trivial to do in software particularly
> for the requiremnt/s of driving a heated bed and
> an extruder heater.
>
> The thermal response of both of these items means
> arelatively low PWM frequency is plenty good
> enough. I think Nophead would perhaps argue that
> On/Off control is suficient.

But the cheap LPC1343 should not have enough IO pins... then I guess the best is to go with "larger" LPC175x, larger in IO pins, flash memory, PWM, ADC and even DAC.


> A timer and interupt is enough.

If we go with "larger" flash memory, we can use FreeRTOS, so no worry to have a dedicated timer. Much like how people do with Arduino milis().


> I usualy discard micro-controlers for having poor
> A to D.

LPC175x: 6 channel 12-bit ADC, 10-bit DAC

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

aka47 Wrote:
-------------------------------------------------------
> On PWM
>
> Don't get hung up on a lack of dedicated hardware
> PWM it is trivial to do in software particularly
> for the requiremnt/s of driving a heated bed and
> an extruder heater.
>
> The thermal response of both of these items means
> arelatively low PWM frequency is plenty good
> enough. I think Nophead would perhaps argue that
> On/Off control is suficient.
>
> A timer and interupt is enough.
>
> I usualy discard micro-controlers for having poor
> A to D.


Can be done but depends on the frequency and comms interfaces. High frequency interrupts have a BIG impact on software design, however anything less than about 40Khz tend to hum. PWM you set a value and update as necessary.

Bang-Bang could be useful, might require a relay though, MOSFETs tend to get very hot and burn out when always on.

Cashino, the leaf card is too expensive, the ngx card is interesting, just concerned if it is too spartan, liking the eeprom though it was one thing I was considering for the new design.

I think the primary consideration has to be the users, A large portion of the individuals who want to use something like the reprap tend to focus on the output of the machine rather than the machine itself, hence makerbot's recent success. They can buy something off the shelf to do the job they want, a number of others, myself included feel the the makerbot solution is too expensive.

Available Eeprom/Flash would allow a standard binary and the ability for the user to configure the control system to their machine.

It doesn't specifically require an external unit, just assigned space somewhere.

Worrying about dev tools is minor, those users specifically interested in developing software for the system will determine their best course of action, what is important is the capability for the user to be able to build their electronics setup in one of the following forms:

1. Buy components, make PCB, assemble, program etc
2. Buy components, buy PCB ...
3. Buy kit
4. Buy pre-assembled

There is another as aka47 has suggested, buy off the shelf components, not designed specifically for use in reprap and fit together to make a system.

Makerbot cover 1-3.5 only supplying part assembled setups, due to the differences between the makerbot machine and mendel.

4 with high volume production is conventional for retail electronics.

aka47's solution is typical for us prototypers, reprap is somewhat unconventional in that it sits in the middle of the 2, being prototype and a prototyper itself, and yet at the same time a fixed variant that user's want and modify.

This unconventional situation is what makes reprap great and at the same time a nightmare for the developers creating the system.

Designing for one limits the scope and marketability of the product, designing for all makes the product over complicated and expensive.

This is the compromise we need to determine.

There are a number of concerns, cost being the major factor and also including, but not limited to:

1.Capable of running the machine, i.e. it works!
2.Availability of parts
3.Capability of users to implement options 1-3 without the need for expensive purchases to perform all actions required to implement system, especially when those purchases are used once, for one specific task and are not used until another system is implemented. Other than actual components of the system itself.
4.Ease of assembly
5.Support of 1 without compromise of EMC capability.
6.Capability of the user to program the system without special equipment.
7.Capability of the user to reconfigure the system without recompiling the firmware.
8.Possibly capable of repair.
9.Possible, Backwards compatibility

There will obviously be more.

Once we have established this list we will have a number of questions that need answers, these answers will form the design criteria for the requirements analysis.

Anodomini2...

RE: item 5 - what do you mean by "EMC"?

Electro-Magnetic Compatibility is what comes to mind for me (an EE), but I don't think that is what you meant.

Building an extensible/expandable system will complicate and slow down development significantly. Note that I am explicitly NOT saying the end result will be, or needs to be, complicated. It is simply that it takes time to clearly define requirements, consider alternatives, and agree on an implementation.

If low-cost AND rapid development are key considerations then it might be best to build a single integrated board that is fixed function.

While the engineer in me would prefer to develop and extensible/expandable system my intuition is that the RepRap community would benefit most by having a low-cost out of the box solution for Mendel as quickly as possible.

Developing a single board solution first and following up with development of an extensible/expandable system might be worth consideration.

TC

So, after further searching I think this is "EMC"...

[www.linuxcnc.org]

Is this right?

TC

EMC machinery is effectively Firmware and Controler free.

There is an argument that the two are fundamentaly opposed. Compromises are not therefore readily available. Particularly if you want ot avoid adding in unnecesary expense for connectors.

I see in these forums many folk describing something as too expensive then go on to propose something that adds cost.

Cost is only realy relavant when looking at the end cost of the whole. Yes the costs of the parts contribute to this but with many things if you make one part more expensive you must make a nother cheaper to compensate.

What do you guys have in mind as a whole cost. ie the cost of a complete machine.

Re Makerbot, horses and courses. I don't think it is expensive in relation to what else is available. I have spent more over the years trying out ideas than I would have spent had I just bough a Makerbot and printed away.

If you want something that you consider less expensive, name your price, then attempt to deisgn to it........

---

Necessity hopefully becomes the absentee parent of successfully invented children.

TC Wrote:
-------------------------------------------------------
> Anodomini2...
>
> RE: item 5 - what do you mean by "EMC"?
>
> Electro-Magnetic Compatibility is what comes to
> mind for me (an EE), but I don't think that is
> what you meant.
>
> Building an extensible/expandable system will
> complicate and slow down development
> significantly. Note that I am explicitly NOT
> saying the end result will be, or needs to be,
> complicated. It is simply that it takes time to
> clearly define requirements, consider
> alternatives, and agree on an implementation.
>
> If low-cost AND rapid development are key
> considerations then it might be best to build a
> single integrated board that is fixed function.
>
> While the engineer in me would prefer to develop
> and extensible/expandable system my intuition is
> that the RepRap community would benefit most by
> having a low-cost out of the box solution for
> Mendel as quickly as possible.
>
> Developing a single board solution first and
> following up with development of an
> extensible/expandable system might be worth
> consideration.
>
> TC


No I meant Electro-magnetic Compatibility

Agreed, the single board approach was my first thought, I am considering seeing if we can do something through hole with vero board, because its cheap, widely available can easy for someone with basic soldering skills to build.

I have ideas for an expandable system already drafted, but getting people up and running quickly and cheaply is the first concern.

My only grief with this approach is the programming requirement, DIP format with enough IO restricts you to the existing ATMega series or PICs (back to square one!)

The other option is a DIP format breakout development board:

1. Mbed, enough IO? And not fully open at this time. But cheap for what you get.
2. LPCxpresso, not very open
3. Other?

The amount of IO is determined by the stepper motor driver interfaces, finding a DIP or PDIP format with Half step capability and a 2 wire STEP/DIR interface, which basically leaves us with the L6208 or L6228, while not cheap they're the only thing I can find, so other suggestions welcome.

The L6228 is cheaper, basically because, the L6208 is 2,8A per phase, where the L6228 is 1.4A per phase, if this is sufficient current this would be a benefit.

My only concern with these is thermal, could you run them from DIP sockets to provide a repair and ease of build capability without compromising heat disipation, i.e. would the generated heat melt the sockets?!

I think we need to avoid the 'extras' such as SD Card, SPI/I2C interfaces etc and focus on the core operation.

So Serial as a minimum is necessary. Or USB if using a development header.

Sad as it may sound the Sanguino could be a good starting point, but I would prefer to consider using the LPCxpresso 1343 board or a variant possibly using an LPC1751/2 or another LPC13xx/LPC17xx variant.

If possible I would like to avoid using a USB->TTL Serial cable. So either integrated into the dev header as a factory option, USB available on the IC or some other interface, mbed would be nice, as I already have one, but that's a personal preference.

A nice option of this construction, there could be an element of flexibility in individuals being able to choose which one they wish to use with some modification of the schematic and circuitry.

After thought, do we want to provide some form of heated bed control?

Given the results that nophead et al have been getting with heated build platforms and reducing warping. I can't see how any future deisgn could not have at least.

2 heater controls (Drive and Sense)
1 Fan Control

The Heater controls are extruder and heated bed, fan is selective cooling. Although I am less convinced about the fan as folk go the other way with heating.

Just in case in the discusion of PWM this item was missed I will say it again...

"The thermal response of both of these items means arelatively low PWM frequency is plenty good enough"

Slow PWM is plenty good enough.

On embeded OS's if you want to go that route put Embeded Linux on with the RT kernel extensions and completly open up the design to incorporate open source. SOme of the code could even be scripted then ans modified in situ without compilation etc.

There are plenty of options floating about for the NXP processors as they are masively popular in WIFI Routers etc.

On my wish list, is :-

1 * Ethernet (Wired)
1 * USB (Host and slave capability)
1 * micro sd card (Pref HDSD) and the Embeded Linux should boot from the SD card so upgrading and cloning is dead easy. (You will still need a boot loader on the microcontroler to initiate it)

There ambitious or what, if we are raising the bar lets do it for real.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

> Sad as it may sound the Sanguino could be a good
> starting point, but I would prefer to consider
> using the LPCxpresso 1343 board or a variant
> possibly using an LPC1751/2 or another
> LPC13xx/LPC17xx variant.

LPC1343 may not have enough IO, right? and also flash memory for code. What is your opinion?

If is to go with LPC1343, then I would prefer to go with cheap Olimex $13 solution. Olimex have many distributer in US, Europe, etc. Like Sparkfun for example. I guess we would have always available boards from them at cheap prices.
Sparkfun gives schematics and example source codes.

I like LPC1343 because users don't need any programmer to flash the firmware, just a USB cable and LPC1343 board behaves as USB flash disk on computer :-)

If LPC1343 is not enough, then maybe LPC175x will be a better choice, if we find a cheap board.


> Given the results that nophead et al have been
> getting with heated build platforms and reducing
> warping. I can't see how any future deisgn could
> not have at least.

Yes, I think is a must! I always print with Heated Bed :-)


> On embeded OS's if you want to go that route put
> Embeded Linux on with the RT kernel extensions and
> completly open up the design to incorporate open
> source. SOme of the code could even be scripted
> then ans modified in situ without compilation
> etc.

Linux means a more expensive board, and I guess we don't need Linux.


> On my wish list, is :-
>
> 1 * Ethernet (Wired)

For what? the LPC175x have Ethernet but it will be for sure more expensive to have it. Could you justify your wish?


> 1 * USB (Host and slave capability)

USB Host for what?
As for USB slave, we already use it and we need it.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

aka47 Wrote:
-------------------------------------------------------
> Given the results that nophead et al have been
> getting with heated build platforms and reducing
> warping. I can't see how any future deisgn could
> not have at least.
>
> 2 heater controls (Drive and Sense)
> 1 Fan Control
>
> The Heater controls are extruder and heated bed,
> fan is selective cooling. Although I am less
> convinced about the fan as folk go the other way
> with heating.
>
> Just in case in the discusion of PWM this item was
> missed I will say it again...
>
> "The thermal response of both of these items means
> arelatively low PWM frequency is plenty good
> enough"
>
> Slow PWM is plenty good enough.
>
> On embeded OS's if you want to go that route put
> Embeded Linux on with the RT kernel extensions and
> completly open up the design to incorporate open
> source. SOme of the code could even be scripted
> then ans modified in situ without compilation
> etc.
>
> There are plenty of options floating about for the
> NXP processors as they are masively popular in
> WIFI Routers etc.
>
> On my wish list, is :-
>
> 1 * Ethernet (Wired)
> 1 * USB (Host and slave capability)
> 1 * micro sd card (Pref HDSD) and the Embeded
> Linux should boot from the SD card so upgrading
> and cloning is dead easy. (You will still need a
> boot loader on the microcontroler to initiate it)
>
> There ambitious or what, if we are raising the bar
> lets do it for real.

A proper embbeded RTOS may be an option, but Embedded linux is not a Real-time OS, we are creating a control system and operations need to occur at specific time intervals. Embedded Linux would not give us this option.

Secondly the majority of Linux is written in C++, I have nothing against C++ in the right environment it can be a very powerful language, but in a Real-time embedded environment, its just a requirement for 20% more RAM and 20% more runtime required to implement the same action.

Something like FreeRTOS might, but I personally would write something bespoke, targeting it at the specific application. This typically results in something using less RAM, FLASH and runtime.

Ethernet is possible, it does have the possibility to add some nice features, but is a big investment in time and money and again a nicety.

SD Card is a nicety, not a requirement for Core operation.

USB device or USB Serial is needed for Core operation, USB Host I assume for memory sticks along with SD Card is a nicety.

The initial version is intended to be cheap, simple and perform the necessary core operations for a Mendel with 1 extruder. Multiple tool heads and the other accessories can come in later iterations.

We are raising the bar in that most home users will be able to build it and it isn't going to cost £150/$200 for the electronics.

Edited 1 time(s). Last edit at 04/05/2010 01:48PM by annodomini2.

annodomini2 Wrote:

I agree and think the same as annodomini2.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

I agree with most of it, but I want to remind people that the Gada prize development is requesting a system that can operate independent of a host computer, which makes mass storage of gcode files essential. So I would upgrade SD card from not required to not required for current core operation, but required in future versions.

I agree that a first draft of system on a board, which mccoy is already working on for McWIres, can exclude mass storage, but the second gen and all future versions should have some form of multiple gcode file storage for standalone operations. Not that even the Arduino/Sangruino size machines can do this easily. The added power of an ARM will make it run faster or with more user interface, but is not essential.

Mike

---

Team Open Air
Blog Team Open Air
rocket scientists think LIGHTYEARS outside the box!

I think there is a lot of underestimating the software costs. This is usually described in units-per-free-time-interval. Or in Tecklish UPFTI. Many call this wasting time.

Some of the ATMEL workshops I attended did AVR in the morning and ARM in the afternoon. Arm is much more a complete solution as the early iPods used ARM processors. Are we building printers or iPods with touch screens here?

The whole advantage of moving to ARM processors --is-- so the home user (poor student) can have their C++ and real time Linux kernel and JTAG boundary debug. Anything else is just the needless complexity of ego and power. Or a veiled attempt to sell controller boards.

Linux has probably been around at least 15 years. I remember it as old and stable in the 1997 time-frame. Given the number of folk using Linux this probably reduces to a billion or so years of UPFTI. At least some hundreds of millions of years.

While things like FREE RTOS are nifty and neat, these do not simplify things for the home user and put cash in pocket. The home user does want a one size fit's all approach. This is why most people purchase a laptop of PDA.

I still think the 2 ton canary in the room is the software/firmware development time. In practice the time it takes to modify download and get the machine running.

Now I am no fan of Arduino. Mostly because I learned something else first. Invested time in writing an embedded micro-kernel for AVR. I may be the odd person out here as I tend to program in assembly with my own micro-kernel. Something that has evolved over ten years time.


Why do people like C++/Java? My observation has been that there is a lot of code base that can be re-used. This saves time. Need a library function to add two floating point numbers? Someone in the last 30 years has written such a thing. No real time needs to be spent. Download and done.

Even though software patents exist. Due to the nature of the way software was given away in the 1950s through 1970s, most people feel that a few lines of code is free and can not be protected. There is no way to prove where those bits came from.

Users expect free code solutions which do not amount to a lot of extra time wasted. Why things are hard, because one is aware the they are going to waste time.


These groups seem to be spinning over and over the same thing the last three months or so. It more and more seems to come down to the same old "Not invented here attitude." which seems to predominate culture. Ironically the printer will allow us to keep the design imagery of our culture intact, or go back to an aesthetically more pleasing one

So what can we propose or do, that will put more cash in the users pocket? Cheaper ARM hardware may amount to more expensive software if C++/Linux is not used. The bar gets set higher less people are able to contribute. The problem more complex.


I still think the core requirement it to move motors, sense temperature and set heaters. Same as an HVAC system. This is precisely the areas ATMEL AVR works best. Smart thermostats and sprinkler controllers


At the moment the more affordable AVR hardware has some supply issues. On the other hand, home builders can use this and make the boards simply. Or even on solder-less breadboards. The program tools for this are cheap at the cost of a nice dinner for two in the San Francisco bay area.

What is the current bottleneck? My guess it is the communications between boards and the different parts of the printer. This combined with the setup needs for the step rate, drive type and extruded width. The remaining is limit fail-safe conditions. The end stops and temperature sensors.

The first of these is USB host side. Simply solved with an FDTI chip. physical cost but no UPFTI cost. The user is not aware of any time to program the interface. Data arrives when needed. Granted USB is a bit awkward on AVR.

Next issue is stepper communications. Ideally lots of pins. This makes it easy to do delay loop waits and single thread programs. Some form of interrupts can be used for the limit fail safe conditions.

Given a RTOS do most users even know how to code multi thread. Semaphores, message queues and mailboxes? Artist look at this and freak out as they have been told this is advanced work. Even though they use the same time slicing to paint a still life of an bowl of fruit.

Am I to understand that a $13 board will uncork this bottleneck and make board to board communications magically happen? That JTAG boundary scan with out a bed of nails will automatically debug the firmware fixing this with additional calls to malloc and free?

Most users just want to print something. Preferably something that will put cash or food in pocket. This is why there are suppliers like makerbot and sparkfun. One of the things that attracted me to the project was the simple distributed electronics.

I still think that an EMC2 solution would be better than the ARM solution. Or else port the EMC2 kernel to ARM. Anything to let the users continue to develop in C++/Java. That is the base line. Anything else is just claiming territory for a new single sourced empire.

-julie

So, I've read what everyone has written to this point. As one would expect, there are plenty of opinions about what the solution should be. Some of it is based on solid arguments and considered thought, and some of it is more off-the-cuff (which is fine).

But, before moving down any specific solution path I think it is more important to define the problem that we (collectively) want to solve. I mostly have questions at this point...

Should we develop an integrated solution or an extensible solution?

What does the electronics for a RepRap cost when based on MakerBot components?

How much time does it take to build one from scratch for Mendel?

How much time does it take to modify pre-built MakerBot components for use in Mendel?

How much time does it take to get it all connected and working correctly?

How much expertise is needed to do any of the above?

What is the likelyhood of a succesful outcome?

What is lacking in these approaches (documentation, availability, whatever...)?

Is it more important to have a pre-built ready to use board, or a board that the end-user can assemble themselves from components?

What other high-level questions should we be asking ourselves?

TC

I must agree mostly with Sheep & Rocket Scientist.

With embedding Linux we are getting a massive boost to what can be accomplished at a relatively light hit, purely because most it has already been written.

SD card or some such is pretty much fundamentally a got to have for the reasons Rocket Scientist mentioned. Also for the fact that software upgrades can be distributed as an image that is written to a fresh card (they are incredibly cost effective) and dropped into the printer with no fuss and no mental effort on the part of a non techy. Flash free ARM processors may turn out to be just the thing (it will live on the SD card, that some NXP processors are already interfaced for).

A point I have to disagree completely with because it is wrong is :-

"but Embedded linux is not a Real-time OS"

The linux kernel has been extend-able with the RT patches for some time now and is proven to be sufficiently Real Time (Thats what the RT stands for) to operate CNC machinery.

The EMC2 projects live images are RT patched and need to be for EMC2 to be as capable as it is.

Don't take my word for it go have a look.


On embeding EMC2 I think there is certainly some mileage in this and you would need SD card to be able to have all the code to hand you would need and for development.

Embeding EMC2 I think is going to take a little bit of work to achieve and there is the question of 2.5D versus 3D versus 4D. to consider. My understanding is that we are currently on the verge or simultaneously controlling more axes than EMC2 currently manages, but am likely to be wrong about this.

It certainly is an option I hve'nt though much about yet.

What I was thinking about was the ability to embed OpenSCAD and control the printer and all its many options via a web interface. The httpd server and embeded linux is already written and in more appliances than you think. My N900 has it. My USB Wireless Hub has it etc etc etc.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

TC Wrote:
-------------------------------------------------------
> Should we develop an integrated solution or an
> extensible solution?
I see three major forks here. 1) Reprap-on-a-Board that mccoyn is doing, 2) the current fixed number of mostly dumb modular units plugging into a single controller board, or 3) a motherboard talking over I2C or other shared buss to a variable number of smart modular controllers.
1) is the absolute cheapest and probably easiest to build, especially if commercially fabbed. It must have some extra pins and connectors for possible future expansion, but is very limited.
2) is also very limited, but more expensive (multiple small boards instead of single large board) but fails to give the full benefit of modularity
3) Truly extenisible, and interfaces should be defined independent of the motor/hardware. So Axis drivers should be in millimeters and speeds, extruders in orifice size and rate of extrusion, heaters in degrees C. That way, when a motor-driver combination is changed, the software and motherboard do not change.


>
> What does the electronics for a RepRap cost when
> based on MakerBot components?
Sorry, no idea there. But good point that making due with what someone else already makes and sells is good. Bad if they are having trouble keeping up with demand.

>
> How much time does it take to build one from
> scratch for Mendel?
Experienced solderer, less than a day. But to spread the wealth, we need a good source of inexpensive pre-built boards. Not everyone can or wants to learn to solder surface mount devices, and they are the most prevalent and cheapest in virtually all parts.



>
> How much time does it take to modify pre-built
> MakerBot components for use in Mendel?
Don't know here either, but sounds like hours at most. Still has the same benefit of re-using parts someone else has designed, tested, made. Same problem of they might not be making them fast enough.

>
> How much time does it take to get it all connected
> and working correctly?
I haven't built one yet, but we suffer from identical connectors. Having uniquely indexed connectors for each axis, extruder, and heater would help with start up wiring, but at added cost. Assembled is much different than running. I am guess that a great deal of time is taken adjust machine parameters, linking tool chains, and working out the bugs. A machine calibration procedure for basic Mendels would help at least with the machine parameter adjusting. Even using option 3 above with all interfaces being in metric units rather than pulses, you still have to calibrate each module for the motor step size, gear or pulley ratios, drive thread, etc.


>
> How much expertise is needed to do any of the
> above?
As is, both mechanical and embedded software skill is needed for assembly and most importantly, for adjusting, tweaking, and getting the whole package to work. Getting the tool chain to work I am guessing take advanced programming skills, too. The best solution here is a single design, parts, software build. Namely, someone needs to sell a flat-pack Mendel kit, with all the parts pre-cut, electronics pre-built, tool chain assembled and ready to load in Windows, MAC OS, and Linux. Then the bar of skill level needed to reach first parts will be much lower. But now that is do more to commonality of packaging than build design. We currently do not have a valid build design that makes it supper easy to go from zero to printing parts in any machine or electronics design.

>
> What is the likelyhood of a succesful outcome?
For people who post on this forum, I would guess 50-90%. For their friends, 10-30%. Once again, guessing, shooting from the hip.

>
> What is lacking in these approaches
> (documentation, availability, whatever...)?
Single, uniform design, parts, package, and documentation on how to assemble, calibrate, test, and make your first custom parts. The electronics design choice made has less to do with this then having a single, common package for many newcommers.
>
> Is it more important to have a pre-built ready to
> use board, or a board that the end-user can
> assemble themselves from components?
Pre-built is the only way to lower the bar of possible builders, and make these more wide spread. I believe that if you want modularity, use a shared bus like I2C, USB, CAN, Ethernet to add new extruders, change axis driver motors, switch from dead-reckoning with steppers to feedback with linear encoders. All this can be made simpler for the less geeky user if the new hardware comes with all the driver electronics attached and precalibrated for a standard configuration.

>
> What other high-level questions should we be
> asking ourselves?
What new features do we hope to need processing power, I/O pins, connectors, controllers, drivers for?

A) More than one extruder
B ) Extruder head, milling head, other head exchanging hardware
C) Extruders with more than one opening size, speed of extrusion.
D) Step counting, or rotation counting of gears pulleys with optical or magentic encoders, feedback from linear optical encoders, ultrasonic or Infrared ranging feed back
E) built in 3D scanning camera(s) and lights
F) Heated bed, possibly zone heated bed
G) Mass storage of
H) User interface independent of controlling computer
I) User controls?
J) additional axes for milling heads or other specialty heads
K) ability to clear or advance the work space/bed to automatically make room for next piece to be made.
>
> TC


My final advice is that if you want to make modular electronics, each satellite boards should not only be wedded to their hardware, but they should include their own small micro with onboard constants to completely isolate the motherboard (and main software) from all the hardware details and take only standardized interface instructions. Anything less is simply splitting the main board up into more expensive parts.

To soften that last statement a little, running motors, stepper motors, solenoids, and heaters requires lots of power, and that means waste heat. Spreading the motor controllers around on modular boards helps with the cooling. Unless you are using something like nophead's IC cooling fan mounted on top of quad Polulu stepper drivers, in which case keeping the heat generating parts close together allows for one main cooling design.

Mike

Edited 1 time(s). Last edit at 04/06/2010 02:47PM by rocket_scientist.

---

Team Open Air
Blog Team Open Air
rocket scientists think LIGHTYEARS outside the box!