Saturday, June 13, 2009
Acceleration Code Released
There is a new release of the Java host software and the Sanguino firmware that support accelerations and decelerations during building.
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.
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.
Labels: file release, firmware, host software
Wednesday, June 18, 2008
Line buffering in the Arduino
Arduino line buffering from Adrian Bowyer on Vimeo.
I have implemented a poly-line buffer in the Arduino code. This means that, when the host software wants to plot a polygon, it doesn't have to wait till one line segment is finished before sending the next. It can just blast them at the Arduino as fast as it likes (it gets stopped when the buffer is full...) and, more importantly, the Arduino always has a line ready to plot so there is no dwell between one line and the next.
The video shows it working. As you can see, the movements are much smoother with fewer and shorter pauses (unless your broadband is a bit narrow, when any jerkiness will be download delays...).
There are still some tweaks that need to be made to the host Java software (this upgrade has very temporarily killed temperature polling, for example...). We'll do that over the next few days.
Meanwhile, if you want to experiment, the host software is here, and the Arduino code is here.
For it to work you have to set the properties variable Extruder0_PauseBetweenSegments to false.
Labels: arduino, buffering, firmware
Wednesday, December 19, 2007
Experimental firmware working
I have now imported Andreas's improvements and corrections to the PIC firmware into Simon's experimental autoconf version of the code for the PIC16F648A. It all compiles, and - when put in a RepRap machine - works (at least it did for me...).
If you want to download it it's at
https://reprap.svn.sourceforge.net/svnroot/reprap/branches/autoconf-firmware
You should probably also look at Simon's instructions on the forum at:
http://forums.reprap.org/read.php?2,3861,3862
We need to do a bit more testing. Then if this all pans out OK this'll become the Subversion trunk version and we'll do a release.
The compiled .hex files (remember they're for a PIC16F648 or PIC16F648A, not a PIC16F628) can be downloaded from here. Unless you have more than one extruder on your RepRap, you can ignore the file extruder_1_.hex.
By putting this:
#define TESTLEN 53
static byte testArray[TESTLEN];
void init2()
{
testArray[TESTLEN-1] = 1;
...
in stepmotor2.c and increasing TESTLEN until the linker barfs I deduce that we have a whole 53 extra bytes to play with in the stepper code now!
If you want to download it it's at
https://reprap.svn.sourceforge.net/svnroot/reprap/branches/autoconf-firmware
You should probably also look at Simon's instructions on the forum at:
http://forums.reprap.org/read.php?2,3861,3862
We need to do a bit more testing. Then if this all pans out OK this'll become the Subversion trunk version and we'll do a release.
The compiled .hex files (remember they're for a PIC16F648 or PIC16F648A, not a PIC16F628) can be downloaded from here. Unless you have more than one extruder on your RepRap, you can ignore the file extruder_1_.hex.
By putting this:
#define TESTLEN 53
static byte testArray[TESTLEN];
void init2()
{
testArray[TESTLEN-1] = 1;
...
in stepmotor2.c and increasing TESTLEN until the linker barfs I deduce that we have a whole 53 extra bytes to play with in the stepper code now!
Monday, December 10, 2007
Half a step forward
I've corrected the PIC firmware so that it now correctly does half-stepping. It's checked back into the Sourceforge repository in Subversion.
This means that we can definitely use the cheaper 200-steps-per-rev stepper motors. You need a bipolar one where the coils can take a voltage of 12v and each use a current of 2A or less.
Details on the forums here.
This means that we can definitely use the cheaper 200-steps-per-rev stepper motors. You need a bipolar one where the coils can take a voltage of 12v and each use a current of 2A or less.
Details on the forums here.
Labels: firmware, stepper motor