Acceleration Code Released

Unfortunately the new firmware is now too big to fit in the Arduino ATMEGA 168 controllers (though the old version that does is still available, of course). However, there is plenty of room in the Sanguino, and we will be supporting the Arduino Mega as a RepRap controller soon.

The new firmware buffers all movements, and so communications with the controller are now asynchronous. This completely eliminates all pauses between one movement and the next.

The main advantage of the new code is that you can run the axis motors at much lower current (as they don't have to hit the feed-rate requested in one step from a standing start) while not compromising build times; indeed, you can set higher maximum feed-rates as the machine now accelerates up to them and decelerates down.

Making a nice shield for the arduino MEGA, which can be used both as breakout and "plug & play" shield is a one project on my table to be finished. Not exactly sure how to place all those screw terminals. This beast of an arduino has just too many pins!

Hi,I've been successfully using a Mega here on my repstrap for a little while now too. As for Pin layouts, I'm basically using the same as thearduino for digital pins 2-13 and analog 0. HOwever, I've moved 2 of my end-stops to 20 and 21 ( X & Y), and my rotary encoder to 18 and 19 because the Mega has 6 more interrupts , and this allows me to utilise the interrupts. Did you know that having a digital read of all the opto end-stops before EVERY single step on every axis is quite in-efficient. NOw, ( for X&Y anyway) I just check the state of a boolean variable that may have been changed by the interrupt. Z-endstop is only checked when the axis actually moves in the Z direction at layer changes, so it's infrequent enough to not matter.

A breakout shield would be very nice. How about putting the 10-pin IDC connectors on it for the stepper controller V2.3 and an 75176A and some RS485 connections? Though we ought to be talking to Zach, who's thinking along similar lines. I'll e-mail him.

The way I want to have the pcbs is having an option when assembling it - An option of making it convenient or hackable - or both. So 10 pin IDC headers for steppers are a good idea, but I would like to have those pins available on the screw terminals also.

While optional RJ485 support seems like a good idea (and I would probably go for the DIP version of this chip), I doubt any of the RJ-45 jacks used in the current design would yet fit onto that pcb.So an idea would be to make it stackable, so you can stack another shield or the second part of the shield on it. But I'm not yet sure how to go on this.

I like the acceleration code, but I'm a bit concerned about the rate of change in this important interface area between machine and computer, specifically the E-codes.

I'm glad that it frees the sanguino/arduino from squaring numbers and doing root calculations on them (pythagorian distance), but how much does the extra handling of the serial input cost in terms of processor cycles. I know that it's handled through a hardware UART, but the interrupts generated should not cause more processor utilization that the calculations by the sanguino.

IMHO it is important to confirm this. I can hardly imagine that it would cost more processing time. But we should consider this before breaking compatibility with toolchains that use M101,102,103 and 108 codes for managing extrusion rates (Skeinforge!). For which I'm writing and debugging a script to convert 3D GCode to 5D. I'll publish it after some more tests.

If we're above the AtMega168's memory limit anyway, we might as well make it backwards compatible with non-4D G-Code...?It could also be an optional part, compiled in or not depending in the wishes of the user (e.g. #define 3D_GCODE_COMPAT ?).