RepRap: Blog

The latest Java host program in the repository now contains code to compute the support needed for overhangs automatically. Above is a screenshot of it working - the L block bottom left is being deliberately built the wrong way up so that it needs support. The layer currently being computed is shown in the diagnostic window. You can see the cross-section of the object itself (blue) and the support for the overhang (brown).




Here it is part-way through the build. You can see the support pattern at the front, and the pillar of the L-shaped object being built at the back.



Here is the build finished. The supported bit is at the front.



Here is the part after taking it off the machine viewed from underneath with the support still in place.


And here it is in its final form with the support separated.

The program allows you to specify a support material for each material in the RepRap machine by name. As the RepRap code allows you to have several logical extruders all talking to the same physical extruder you can use a material to support itself by copying its entries in the preferences file (sort the file first to bunch them together) then renaming them from Extruder_0 to Extruder_1 (or whatever). You then change the infill pattern of the support to whatever you want. Here I set it not to outline, only to infill, and not to change the direction of the ply between layers.

The support cleaved pretty easily from the part with a penknife blade, but I suspect that this would have been harder had the underside of the part been undulating rather than flat. Of course two extruders would allow - for example - a friable paste to be used as a support (my current favourite: cornflour mixed with a gel of PVA glue and methanol - to be blogged when I have some results...).

The supports are only computed by the host software when it is saving G-Codes to a file. The reason for this is that the software has to do the calculation in reverse - from the top down - so that it can know what's immediately above the layer it is currently creating. It can only do that by writing each layer as a temporary file, then concatenating them all in reverse order to actually build from the ground up when it has finished.

If you are interested in how the use of a CSG representation makes the support calculation easy to code, take a look at the

     private void supportCalculations()

function in the class LayerProducer.

As you can see, I have not exactly tested the code on the world's most complex shape, so all this should probably be regarded as experimental...

I'm off for a week to give RepRap talks in Wales and then Spain. When I get back I'll try it on something a bit more challenging, and when it's working properly we'll do a release.

Labels: host, java, overhang, support

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've changed the RepRap control panel in the Java host software so that it'll work under Java 1.5. It used to require Java 1.6 (which isn't on the Mac yet), so moving it back a step was a real pain. It's checked into the svn repository.

It's mostly there, plus a little added functionality. You can now pause a build, Sto(re) the current machine coordinates in the XYZ tab, hit the Rcl (recall) button to load those stored coordinates into the destination location, move the machine about, restock the extruder, etc etc, then hit Rcl again then Go there to get back to where you left off, then resume the build. It turns the extruder off when you pause, but doesn't automatically turn it on again when you resume (as you won't always want this). Turn it on in the extruder panel before resuming if that's what you want.

You need swing-layout-1.0.3.jar in your classpath for all this to work. This requirement will go away when we finally move to Java 1.6 (as its equivalent is in there already), but for the moment it's in the lib directory for your convenience.

Labels: host software, java

I did a foolish thing. I fixed a bug in the Java host code (in the bit that algebraically simplifies CSG expressions) and, instead of just checking that back in, I also spent some time tidying the code, then tested it, then checked in the lot. That gave Subversion revision 1333.

Unfortunately my tidying introduced several new exciting features that many users would have found not entirely helpful that were not apparent in my testing... Sorry.

Now (with Zach's help - thanks), the code has been reverted back to the version that worked, to which I have applied just my CSG fix.

The current revision is 1369. It's not perfect. But it's a lot better than 1333...

Next thing: fix the memory management...

Labels: host, java, software