RepRap: Blog

Ever since we decided to separate the computation of slices from the driving of the RepRap machine by writing the computed slice movements to a G-Code file then subsequently re-playing that on the machine, we have known that that strategy would improve quality. This is because it removes dwells and delays from the build caused by the slicing code having to perform (sometimes quite intensive) computations. The G Code file has exactly all the right speeds and delays in it, and there is no significant delay in transferring the commands to the RepRap machine from simply reading a file.

This improvement was confirmed experimentally and in production by Nophead's Hydraraptor work, and by Zach's ReplicatorG G-Code RepRap-driving program.


Here is the first build out of the standard RepRap Java host software updated as in the post below. It's the RepRap coat hook. I computed the slices and saved them to a GCode file (this took about 12 minutes). Then I replayed the file (this took about an hour and a half). This was on my home RepRap, driven by a Sanguino running the Sanguino GCode firmware extruding ABS at 240^oC.

Above is the coat hook unretouced just after the build finished.


And here is it after brushing the hair off. The quality is almost as good as the superb results that Nophead gets, at which I am well-chuffed as I haven't finished tweaking the parameters yet.

One tiny bug became aparent: the Java hangs writing the GCodes to a file if the RepRap machine isn't plugged into the computer's USB port, even though nothing is going to the RepRap machine at that stage. Now I'm off to hunt that one down; I suspect I may have been too clever adjusting thread priorities...

Tomorrow, Ed and I will get together in the lab at Bath to make sure this all works with the Arduino (which we have on the lab machine) as well as the Sanguino.

Labels: g-code file, host software, java, Sanguino

I have been working on the Java RepRap host software. The latest version (https://reprap.svn.sourceforge.net/svnroot/reprap/trunk/reprap) allows you to:

• Load STL files and print them on a SNAP RepRap (PIC or Arduino).
• Load STL files and print them on a GCode RepRap (Arduino or Sanguino).
• Load STL files and print them as GCodes to a file.
• Load a GCode file and print it on a GCode RepRap (Arduino or Sanguino).

The next step is to put a simple GCode interpreter in there that will allow the final combination: sending a GCode file to be printed on a SNAP RepRap. Also, before doing a release, I need to do a bit more testing (so far I have tested the Sanguino stuff but not the Arduino, for example, as my home machine is Sanguino). I also need to get the progress indicator working with the print-from-GCode-file option; it works with all the others.

The transmission using GCodes is buffered through a separate thread which makes it pretty smooth. This works particularly nicely with GCodes stored in a file (as with Zach's ReplicatorG), and gives good-quality builds. As soon as I've got something more interesting than a cube, I'll post it.

I've had to change a few preferences values - see http://www.reprap.org/bin/view/Main/RepRapSoftwarePreferencesDocumentation.

Finally, you'll see that there is a greyed-out button for "Load RFO". This is the format that Zach proposed along with the Fab@Home guys for multiple-material builds (see http://reprap.org/bin/view/Main/MultipleMaterialsFiles). Watch this space...

Labels: g-code file, host software, java, Sanguino

I stuck my stripboard Sanguino (red S) on my RepRap machine to see if it would fly. I want to do this so I can play with more than one extruder at once, for support material and so on.

Getting it to start working was pretty simple - I redefined the pins in init.dist.h for the Single Arduino Snap code, and the RepRap Java software started talking to it straight away.

With a bit of messing about I got the axes moving, then - when I put the wires on the pins I'd actually defined in the header file - the zero opto-sensors worked too.

But I got a lot of comms errors. These were much reduced by adding:

for(int i = 1; i < 32; i++)
{
pinMode(i, OUTPUT);
digitalWrite(i, LOW);
}

to the initialisation code, then letting the classes set the pins they actually use as they want. (Incidentally, the Arduino code doesn't do this for all the pins it uses - maybe it should...)

I suspect we have some stray interrupts from somewhere (like noise on unconnected pins), and also some code in there that switches off interrupts for too long, and so it loses bytes from the input stream.

The comms errors are still too bad to make the extruder go properly, though the temperatures are being measured fine.

If you want to play it's all at: http://reprap.svn.sourceforge.net/viewvc/reprap/trunk/reprap/firmware/Sanguino/

The pin assignments are in the OpenOffice spreadsheet here.

Tomorrow, if I have time, I'll see if Zach's upgrade just below cures some of the problems...

Labels: Sanguino

I have been asked to blog pictures of my stripboard version of Zach's Sanguino. Here goes:


The cable top-right is the USB <-> TTL serial lead. The double-row 6-way connector top left is the ICSP connector, which you'll need to put the bootloader into the machine before you use the USB connection.

If you flip the board around a left-right axis in the middle of the above picture it looks like this:


If someone has time (unlike me... sorry) to do a proper set of stripboard connection diagrams that'd be really helpful.

Labels: arduino, electronics, Sanguino, stripboard