Faster way to download gcode to sd?

[limhyon]

Hi. A faster way to download gcode to SD card using COM port exist? Current download method seems to be writing by simulating printing sequence from M28 to M29 command.

I think employing Xmodel protocol or binary gcode and decode seems to be a candidate. How is your opinion?

[thecrazy]

Would it be possible to modify our current electronics?

On Thu, Feb 7, 2013 at 12:48 PM, Chris notifications@github.com wrote:

All it would need is to power the FTDI chip from USB and opto couple the serial lines to the Atmega to break the ground loop.

On 7 February 2013 17:45, Frederic Defoy notifications@github.com wrote:

Just wondering, how does HP, canon, lexmark etc.. do it? they all use usb and have no problems.

Wouldnt it be possible / better in the long run to simply work on a ramps 1.5 thats compatible with current firmwares but does the USB part properly?

On Thu, Feb 7, 2013 at 12:15 PM, Chris notifications@github.com wrote:

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13247164>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249749>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249953.

[nophead]

Only if you cut tracks and hack an opto coupler on,

On 7 February 2013 17:57, Frederic Defoy notifications@github.com wrote:

Would it be possible to modify our current electronics?

On Thu, Feb 7, 2013 at 12:48 PM, Chris notifications@github.com wrote:

All it would need is to power the FTDI chip from USB and opto couple the serial lines to the Atmega to break the ground loop.

On 7 February 2013 17:45, Frederic Defoy notifications@github.com wrote:

Just wondering, how does HP, canon, lexmark etc.. do it? they all use usb and have no problems.

Wouldnt it be possible / better in the long run to simply work on a ramps 1.5 thats compatible with current firmwares but does the USB part properly?

On Thu, Feb 7, 2013 at 12:15 PM, Chris notifications@github.com wrote:

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13247164>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249749>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249953>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13250399.

[buildrob]

You can however also buy inline USB optoisolators off-the-shelf. The problem currently is not the USB, Ethernet or serial - its the link between the transciever and Arduino. Thats where the flow control-less 250kbps limitation comes from - there other interface options available like SPI.

[nothinman]

Isolation has to be between atmega and ftdi/whatever_transceiver. Putting something behind that doesn't solve the problem of common ground. I furthermore have no interest, personally, in purchasing inline optoisolators, as it's a trivial change and requires only one component. Maybe resistors. I'm lucky as my ground noise is low and allows me to communicate at 1Mbps. But I will actually hook this up to a scope and check another Sanguino board... Flow control has got nothing to do with it. I run SPI devices happily at 20MHz without any flow control and it works perfectly. This is slow in digital terms... But if you have a common ground for multiple devices, including analogue inductive ones (motors), digital, and a ground coming from another source (PC)... I wouldn't expect any magic... I'm surprised it works at all :)

[nophead]

The isolation can be either side as long as the ground loop is broken. Could be between USB and FTDI, FTDI and Atemega or between Atmega and its I/O. The simplest is the FTDI to atmega connection.

On 7 February 2013 22:26, nothinman notifications@github.com wrote:

Isolation has to be between atmega and ftdi/whatever_transceiver. Putting something behind that doesn't solve the problem of common ground, which causes noise. I furthermore have no interest, personally, in purchasing inline optoisolators, as it's a trivial change and requires only one component. Maybe\ resistors. I'm lucky as my ground noise is low and allows me to communicate at 1Mbps. But I will actually hook this up to a scope and check another Sanguino board... Flow control has got nothing to do with it. I run SPI devices happily at 20MHz without any flow control and it works perfectly. This is slow in digital terms... But if you have a common ground for multiple devices, including analogue inductive ones (motors), digital, and a ground coming from another source (PC)... I wouldn't expect any magic... I'm surprised it works at all :)

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13265256.

[bkubicek]

6n137 is your friend.

On 2/7/2013 8:39 PM, Chris wrote:

Only if you cut tracks and hack an opto coupler on,

On 7 February 2013 17:57, Frederic Defoy notifications@github.com wrote:

Would it be possible to modify our current electronics?

On Thu, Feb 7, 2013 at 12:48 PM, Chris notifications@github.com wrote:

All it would need is to power the FTDI chip from USB and opto couple the serial lines to the Atmega to break the ground loop.

On 7 February 2013 17:45, Frederic Defoy notifications@github.com wrote:

Just wondering, how does HP, canon, lexmark etc.. do it? they all use usb and have no problems.

Wouldnt it be possible / better in the long run to simply work on a ramps 1.5 thats compatible with current firmwares but does the USB part properly?

On Thu, Feb 7, 2013 at 12:15 PM, Chris notifications@github.com wrote:

Yes Ethernet is much better than USB because it is isolated. I run my production machines with Ethernet and don't have any problems, apart from Win7 disrupting the comms occasionally until I disabled DHCP. I think it must block all comms while it renews the lease or something. XP was fine with DHCP enabled.

On 7 February 2013 17:09, nothinman notifications@github.com wrote:

Or your system when it doesn't support say 250kbit, or 1Mb ;) I personally have no problems with serial, but I know that people do. Ethernet would be a nice step forward (into the right direction too). I can't imagine anyone having problems with Ethernet...

— Reply to this email directly or view it on GitHub<

https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13246588>.

— Reply to this email directly or view it on GitHub<

https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13247164>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249749>.

— Reply to this email directly or view it on GitHub< https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13249953>.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13250399.

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/382#issuecomment-13255266.

[buildrob]

@nothinman wrote: Flow control has got nothing to do with it. I run SPI devices happily at 20MHz without any flow control and it works perfectly. I disagree; but your argument is tangential - protocols like I2C and SPI don't need explicit hardware flow-control because the host implicitly has control over the device's sending of information - but that's my exact point, as I said, the problem is the current flow control-less 250kbps serial UART link being used with the transceiver. I think again we're arguing the same thing.

[nophead]

If the UART needs flow control it means the CPU can't handle the interrupts fast enough, which would be roughly the same with SPI.

On 7 February 2013 22:46, Robert F-C notifications@github.com wrote:

@nothinman https://github.com/nothinman wrote: Flow control has got nothing to do with it. I run SPI devices happily at 20MHz without any flow control and it works perfectly. I disagree; but your argument is tangential - protocols like I2C and SPI don't need explicit hardware flow-control because the host implicitly has control over the device's sending of information - but that's my exact point, as I said, the problem is the current flow control-less 250kbps serial UART link being used with the transceiver. I think again we're arguing the same thing.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13266689.

[thecrazy]

I'm willing to try this. Soldering, cutting traces, hacking stuff etc, thats in my line of skills but I dont speak electronics so i'd need some precise instructions.

That being said, excuse my ignorance on the subject but, lets say I do this and fix the ground loop how would this fix our speed issue? The connection would be more stable and we would be able to use a higher bitrate for the com port? is that the idea?

Since I use a double conversion online UPS doesn't that fix the ground loop issue for me? My printer, the computer and everything is connected to it and its been rock stable since I did that. Cant get any cleaner power. If you guys think its as good as isolating the grounds I could just try faster com port speeds right away and see how high this thing will go.

[nophead]

It won't increase the speed. just fix the random disconnects that people get with USB.

On 8 February 2013 16:47, Frederic Defoy notifications@github.com wrote:

I'm willing to try this. Soldering, cutting traces, hacking stuff etc, thats in my line of skills but I dont speak electronics so i'd need some precise instructions.

That being said, excuse my ignorance on the subject but, lets say I do this and fix the ground loop how would this fix our speed issue? The connection would be more stable and we would be able to use a higher bitrate for the com port? is that the idea?

Since I use a double conversion online UPS doesn't that fix the ground loop issue for me? My printer, the computer and everything is connected to it and its been rock stable since I did that. Cant get any cleaner power. If you guys think its as good as isolating the grounds I could just try faster com port speeds right away and see how high this thing will go.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13299233.

[thecrazy]

Just for fun, I just tried my ramps at 460800 baud rate and I am able to connect with, repetier host and it reports no errors. I'll have to test more tonight.

[daid]

Just for fun, try putting an USB-Wifi dongle in the same area and see if you still transfer fine, we've had lots of problems because of one of those yesterday.

[thecrazy]

Turns out that im allready getting a few errors at that baud rate but the object did print correctly. Wifi will just make it worst, maybe im just crazy, but the printer seemed more... fluid at that speed. I must be nuts.

[nothinman]

You will get errors, since avr's clock is set to 16MHz or 20MHz. Try running it at 500kbps instead of 460.8kbps.

[ErikZalm]

A baudrate above 115k2 is not tested. I never timed it. If the characters come to fast the firmware loses characters. A good test is a g-code a line that is made from many small segments. (3-5mm) Use a very high speed. Repeat this line many times and check for communication errors.

[thecrazy]

Makes sense, I will try 500kbps and update.

@ErikZalm im not too sure im following you regarding the test file.

[nothinman]

@ErikZalm "If the characters come to fast the firmware loses characters." Do you mind to tell us why?

[bkubicek]

I have all ready explained it, see my previous post. On Feb 14, 2013 7:21 PM, "nothinman" notifications@github.com wrote:

@ErikZalm https://github.com/ErikZalm "If the characters come to fast the firmware loses characters." Do you mind to tell us why?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13570156.

[JustAnother1]

@nothinman "If the characters come to fast the firmware loses characters." The problem is the performance of the AVR. Every time a byte arrives the AVR has to copy the byte to the buffer and if the message is complete is has to process it. The performance is limited so if the characters come in faster than they can be processed then where should that byte go once the buffer is full? And in a situation where data comes in faster than it is processed every buffer will fill up, just a question of when.

[thecrazy]

Mmm... well then its a lost battle. If marlin supported the R2C2 i would allready be using it but i dont know what firmware its running and what its worth. If the community could settle on a arm based controller then we could start to move on.

see http://www.3dprinting-r2c2.com/

[nothinman]

@JustAnother1 That's some nonsense, Sir. I could fill up the buffer at any baud rate. But there is no way a byte arrives faster than it can be processed. As far as I'm aware, maximum clock for the USART is F_CPU/8. There will always be time to at least store data in buffer, since transmission is at least 8x slower than the master clock. Every time "byte arrives" an interrupt happens. Given 250kbps, an AVR running at 16MHz is 64 times faster than the transmission rate, so you have 64 clock cycles before the instructions. That's plenty of time to fill up the buffer. What happens when it fills up? You tell the host you're full, and ask host to check again in say... 100ms? 500ms? a second? Or tell the host you'll let him know once you can spare some storage again ;)

[nothinman]

@thecrazy R2C2 is just a different, and yes, faster, CPU. But at 200 euros per board I really see no benefit. Do you?

[ErikZalm]

@nothinman The problem is that the interrupt handling of the atmega is very limited. If we can use all the performance for the serial connection the baudrate can be high. But the most important process is the stepper control. The stepper control is coupled to a timer interrupt. If it is in this interrupt it can not receive characters. To make the baudrate of 115k2 possible I check for chars in the stepper interrupt.

[JustAnother1]

@nothinman 64 clock cycles is not much and "What happens when it fills up? You tell the host you're full, and ask host to check again in say... 100ms? 500ms? a second? Or tell the host you'll let him know once you can spare some storage again ;)" could be the definition of flow control the reason for the problem was if you remember that there is no flow control ! If you don't check buildrob's comment " the problem is the current flow control-less 250kbps serial UART"

[buildrob]

@nothinman ... And that is why the lack of flow control can hurt us. Its lack is mitigated by the fact that the host will not normally send the next gcode command until it has an ok to the last command. Of course for file transfer (the topic of this thread) it is far more of an issue.

[nothinman]

@ErikZalm are you saying that we disable interrupts once we enter stepping subroutine, or that because you're inside ISR it can't get terminated by another ISR? Sorry, just trying to understand the problem. I've abandoned megas a while ago, and started using xmegas (and you can terminate an ISR with another ISR, given it has higher priority).

[nothinman]

OK, I see, I read it all, but I didn't realize what was meant by the "flow control". Uff... ARM time then? ;-) Will be a pain in the backside to port it all :/

[JustAnother1]

@nothinman AVR has only one Interrupt priority, so no Interrupt that interrupts an interrupt. Also not sure i would want the stepping interrupt get interrupted,.. For the ARM porting part: Arduino now has the Due (http://store.arduino.cc/eu/index.php?main_page=product_info&cPath=11_12&products_id=243) for 39€ supported by the Arduino IDE and should be compatible with Libraries and shields,..

[thecrazy]

@nothinman the r2c2 is indeed expensive, im not saying we should go for that controller but I have looked at the new controller initiatives out there and all I can find are rehashes of the same old ramps or sanguinololu designs. A small update here or there but nothing serious about moving on to a new generation of controller.

[JustAnother1]

@thecrazy I'm new to the 3d printing community but my impression is that most contributors have their own setup and do things to make their setup work. And also the community seems to be very diverse. In such a setup small changes are easy to do, but big changes are not possible as they would require a team of people to work together on something that also solves other peoples problems. This is possible in other communities, but I haven't seen it here.

[nothinman]

@JustAnother1 Yes, I did look at Arduino Due. But porting still won't be easy (feel free to correct me if I'm wrong), as a lot of stuff uses AVR-specific stuff and just can't be 'ported' by means of changing a CPU from a drop down. Interrupting stepping wouldn't hurt a lot, since a step has to last for a few cycles, to satisfy minimum pulse width for Allegro controllers, and interrupt-fetch-store wouldn't take more than a few cycles. But either way, can't be done so no point of continuing this discussion... :) Arduino Due would be good; porting would be painful though...

[daid]

@JustAnother1: The DUE is incompatible with just about anything. It uses 3.3V IO, and a different kind of chip. Almost none of the Marlin code uses the brain-dead Arduino glue, and accesses the registers directly, because that's a gazillion times faster. So it's not DUE compatible, nor are most of the libraries. And none of the boards are compatible as they are designed for 5V IO.

I also know of about 4 efforts of making ARM based RepRap boards. The problem is not that there are not people working on it, but that there is currently not a single platform or real sharing and working together. Also, setting up the development environment is currently not easy for those ARM boards, which is holding people back. Then there is the price, and the fact that the Arduino is working "good enough" for most people.

[JustAnother1]

@nothinman @daid OK then porting is a lot of work. But It can not be too much if 4 teams are working on separate solutions,.. @nothinman The Interruption of the Interrupt would probably move the step (let it start later). If the ISR is done with the Important stuff and would only wait to get the step wide enough then it could re enable the other interrupts and could after that been interrupted. but I assume that no unimportant (interruptible) stuff is done in the ISR. So that would not help.

[daid]

@nothinman: An AVR interrupt takes 5 cycles. The following jump takes 3 cycles. An return from interrupt takes 5 cycles. With BAUD=F_CPU/8 then you have an interrupt every 80 cycles. Just the interrupt handling already would take 17.5% of the CPU time. Without handling the data. Add some handling of the data (a fetch&store would require a register, so also a push and pop, quickly adding 10-20 cycles easy, most likely more as you need bounds checking). Thinking this would not effect the stepping is just plain silly.

[nothinman]

@daid I thought an ISR would be 1 clk, but 5 cycles for in and out? I may want to take that back indeed...

[nophead]

When loading the SD card you could suspend the motor interrupts and just do serial comms as fast as possible.

On 14 February 2013 22:54, nothinman notifications@github.com wrote:

@daid https://github.com/daid I thought an ISR would be 1 clk, but 5 cycles for in and out? I may want to take that back indeed...

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13583587.

[buildrob]

Unfortunately you still need to write to the SD card which is slow. I actually got Zmodem to Ram working well - writing to SD is more difficult and requires window management on the senders side as well (if even practical at all - it may well be that the SD writes always result on a serial buffer overrun - short of a full serial ISR rewrite for use just during transfers which is starting to sound excessive)

[thecrazy]

Some of you guys here seem to know a lot about the inner workings of the cpu driving our ramps, so please let me ask this question: if money wasnt an issue and somehow we managed to get atmega on our side, would it be possible for them to hatch a new chip that conserves compatibility with the mega 2560 ( and marlin) but with more horsepower and a few extra bells and whistles to adress the shortcommings of the current platform?

[daid]

Atmel, the producer of the AVR chip line, which includes the ATMega2560. Most likely produces billions of AVR chips each year. We are just a tiny dot on their radar. As they produce for the automotive and aviation industry. Even Arduino is most likely small fish for them, but more important as Arduino produces lots of exposure of the chip.

The ARM chips are suitable replacements, but require some more work. But at some point there will be a good ARM board for RepRaps. I'm still wondering if it would be interesting to produce an Linux capable RepRap board. Maybe a dual-processor board, or the stepping in a real-time kernel.

[paenian]

There is an incredible variety of ATMega microcontrollers ( http://www.atmel.com/products/microcontrollers/avr/megaavr.aspx), but none of them run faster than 20Mhz.

Makes me think that there's some sort of limitation there... the Xmega line runs at 32mhz, though - presumably a redesigned core. Porting to an xmega would be the easiest upgrade, but still quite a lot of work for merely doubling the speed.

Paul

On Fri, Feb 15, 2013 at 3:52 AM, daid notifications@github.com wrote:

Atmel, the producer of the AVR chip line, which includes the ATMega2560. Most likely produces billions of AVR chips each year. We are just a tiny dot on their radar. As they produce for the automotive and aviation industry. Even Arduino is most likely small fish for them, but more important as Arduino produces lots of exposure of the chip.

The ARM chips are suitable replacements, but require some more work. But at some point there will be a good ARM board for RepRaps. I'm still wondering if it would be interesting to produce an Linux capable RepRap board. Maybe a dual-processor board, or the stepping in a real-time kernel.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13597506.

[thecrazy]

I was thinking that with the size of the reprap community (worldwide, its huge) a kickstarter backed by the right people would probably generate enough money to have a few people working full time on a new electronic platform and port marlin.

If you look at the kind of money the printrbot, form1, robo3d and several other reprap oriented kickstarters have generated you can see how this would be possible. Its exactly the kind of thing that would get the community going in the same direction in regards to the next gen controller platform.

Now, obviously I don't have the skills to design this new platform but I could certainly help organize things. There is a few big names already reading this thread, anyone interested in discussing this?

[daid]

It's more a time then a money issue.

[thecrazy]

I guess your right but at the right price money can buy time.

OR we can just wait another 5 years and things may evolve by themselves.

[JustAnother1]

Moving to Xmega or an over clocked mega would also need porting/ adoption of the timer configuration. So probably not worth if for the small performance increase. One other option that is missing in Daid's list is a CPU and an FPGA for the time critical stepping. That would take a lot of CPU load of of the CPU and into the FPGA. The FPGA has no problem with real time stuff. And the CPU would loose all real-time requirements so that even an embedded Linux would do. But this solution is even more effort than porting marlin to ARM,..

I would be wiling to trade time for money, but I won't do it all alone. This discussion should be moved to somewhere else.

[nophead]

Is there an open source FPGA compiler available? That has always put me off using one for an open source project. Also it raises the bar skill wise for people to be able to contribute.

On 15 February 2013 15:54, Lars Pötter notifications@github.com wrote:

Moving to Xmega or an over clocked mega would also need porting/ adoption of the timer configuration. So probably not worth if for the small performance increase. One other option that is missing in Daid's list is a CPU and an FPGA for the time critical stepping. That would take a lot of CPU load of of the CPU and into the FPGA. The FPGA has no problem with real time stuff. And the CPU would loose all real-time requirements so that even an embedded Linux would do. But this solution is even more effort than porting marlin to ARM,..

I would be wiling to trade time for money, but I won't do it all alone. This discussion should be moved to somewhere else.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/382#issuecomment-13612852.

[nothinman]

xmega isn't the best, it's better than mega, but ARMs are cheap and to port it it would take more-less the same amount of time, so why not do it properly... and there's so many ARMs, from ~60MHz up to hundreds of megahertz, so it's unlikely we will run out of power... but it's again a lot of work... get funding via kickstarter to build something for the people and give it away for free? well, good luck. I'll do it for free in my spare time, as a hobby, but I wouldn't like the idea of everyone watching me and pushing me, "because they pay me".

[thecrazy]

@nothinman I know what you mean, I wouldn't want the development to be rushed either, I was more thinking of trying to get funding via kickstarter, not sell the new controller there. There could be some rewards, printed trinkets and printed kits for the higher tiers (just the plastic parts). I could donate time and plastic myself to print some kits. I'm sure other people would help too. Even if we get just 50k out of this, surely that would be a good start?

Maybe enough to get someone to port marlin to ARM. Would it be possible to use something that already exists out there to develop the bulk of the port and add the finishing touches once the final hardware has been completed?

R2C2 for example uses an ARM, even if its expansive it could be used just for development.

[buildrob]

@JustAnother1 I like the idea of the FPGA but it does raise the skills required to contribute and is not really necessary. Consider this: you can consider the Arduino as implementing the minimum real-time components (i.e., the bit you would otherwise implement in the FPGA). You would then use an ARM CPU / miniPC to implement the higher layers. We've demonstrated the Arduino has adequate power to drive the motors - especially if we changed the top end interface to use a more appropriately coded interface (minimal binary encoded commands, proper interface like SPI/I2C). Wouldn't this be just what you are implementing in the FPGA?

You can have controller boards which then have both an Arduino for the real-time component (ala the FPGA) and an ARM CPU. NinjaBlock boards (http://ninjablocks.com/) are a good example of this architecture. It also mimics what people are doing with driving the Arduino from a Pi box - develop that and put it on the same board (and optimize the interface between them). Of course whether they are on the same board doesn't really matter from a software point of view - which is excellent because it promotes take up before single boards are prevalent.

[JustAnother1]

@buildrob replacing the FPGA by an AVR would be a possible first step. The ARM in this scenario could be something like the raspberrypi. It would then run a Linux have a nice 7" LCD Display with a touch screen and Ethernet. It would have a Software like ReplicatorG/Cura/Makerware and a slicer and the whole system would be like a 2d printer. You could also throw in a FabScan(http://www.thingiverse.com/thing:14198) to make it a copy machine. A lot is possible if you have a team of people working on it. At least on the electronics/Software side 3dprinting has a lot of room to grow.

The real problem is not that there are no solutions for the problems. The real big issue is that daid knows 4 teams that each develop their own ARM Board. And as he said: "The problem is not that there are not people working on it, but that there is currently not a single platform or real sharing and working together." There are probably more people working on this or other electronics related things that we don't know of as they are not releasing their stuff. As nobody knows which software R2C2 uses they might be the 5th team.

We need to find a solution for this problem!

I want to help move 3d printing forward, but which team should I support?

I have a printer with a Marlin Firmware. So helping make the Marlin Firmware better could also help make my printer better. @thecrazy The work on porting Marlin to ARM could be started without a Hardware available. But will one of the 4 or 5 or how much teams there are will do an Hardware that has similar features to what Marlin supports? Probably! But who knows. When I look at the Ideas we are throwing around @nothinman "up to hundreds of megahertz,", my Idea of FPGA, @daid "Maybe a dual-processor board, or the stepping in a real-time kernel." and what else. The chances are good that the Firmware for the winning solution will be very different from what is Marlin today.

I can start without a Hardware, but I can not start without an Idea of what I want to develop!

To move 3dprinting forward I think we must create that single platform with real sharing and working together. Everything else will follow.

[buildrob]

The reasons why I like the idea of the Arduino/Pi split controller are: a) the hardware is easily available off the shelf without designing new boards (that can come later as a cost reduction exercise) - much more rapid to get started. b) but FAR more importantly, people currently invested in Arduino controller boards can upgrade to the new platform without throwing away their current controller hardware, [e.g., buy a $35 Arduinio board and connect via I2C] That is going be a MASSIVE boost in developing critical mass. c) all the Marlin driver code can be directly leveraged on the Arduino rather than starting from scratch - massive saving in time. d) we are not trying start from scratch with a custom RepRap ARM Linux solution either - the Pi is very well developed distro and environment. [That's probably a weak point as I'm sure there are equally good distros available for just about any ARM - but Pi does currently have a lot of community focus - like Arduino.] e) having an open interface between then Arduino and Pi will also promote different projects. Now you could say that the community working on different projects instead of the one true project is bad but its the reality of the situation and having an open interface interface between the two components means that at least the different efforts can build on each others shoulders in a fashion.