Accelerating RepRap from Adrian Bowyer on Vimeo.
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.
I've been using the Arduino MEGA for quite a while now. Other than needed pin changes, I see no reason why it should not work.
ReplyDeleteYes - I did a test compile and load to a Mega, and talked to it with the Java Host software, and it all worked fine. I just haven't wired it into a RepRap machine yet.
ReplyDeleteHave you posted the pins that you use anywhere? I know that Zach's working on this too, and we should all agree on a convention.
I'm using (digital) pins 22 for Z, Y and X axis in ascending order, pins 2-3 for extruder heater and DC motor (driven by PWM), pin 0 (analogue) for temperature sensor.
ReplyDeleteFor a standard pin configuration I would recommend using digital pins starting from 22 for X, Y, Z, Extruder stepper 1 & 2
PWM: Pin 2 for heater, 3 for fan, 4 for heater 2 and 5 for fan 2
Temperature sensor: (analogue) 0 and 1 for extruder 1 & 2
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!
Why don't people using Gen 2 electronics just upgrade to AtMega 328's?
ReplyDeleteHi,
ReplyDeleteI'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.
Buzz
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.
ReplyDeleteAdrian,
ReplyDeleteThe 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.
Anyway I'll prepare another prototype and see how it works out.
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.
ReplyDeleteI'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...?
ReplyDeleteIt could also be an optional part, compiled in or not depending in the wishes of the user (e.g. #define 3D_GCODE_COMPAT ?).
Yes - I'm going to add an option to make it backwards compatible with the non-4D code with a #define. In fact, the code is all in there and commented out...
ReplyDeleteAll moves are now buffered, so the comms happen asynchronously. In practice, I've noticed no problem with this, nor any delays.
I don't think we need the RJ 45 jacks on a shield - each comms connection only needs two pins. Zach just did the RJ 45 thing to save people having to make up their own cables.
Yup
ReplyDeleteI must confess to being a screw terminal fan myself. They are a touch more flexible with using what ever wire is lying around too.
IDC is neat but again really is biased towards ribon and clever assemblies.
Great for volume production pants for one off bodging.
There are screw terminals available on the same pitch as SIL pin headers (0.1" or 2.45 mm) These make excellent drop in replacements. I used them on my Sanguino Kit.
Looking forward to playing with the Arduino Mega. it looks great. More pins too.