Oh, the joy of 3D printing

There is calibration to do, and repositioning of the Z-plane rods. Despite all this I printed (a kind of) PTFE retainer.
The first rafts didn't stick at all. Then they did but the extruder would stop or the print would be fudgy so the nozzle got stuck. Then despair came. And today I managed to complete the thing.



And, well err, it does resemble most of the design ;-)

Jim, it's alive!

The MakerBot is built and indeed it prints.



The first print ever, a testcube



Now back to my wishlist of things to print. For tweaking and operational MB stuff I keep an eye on the MakerBot Operators Blog.

MakerBot body assembly

In november I ordered a MakerBot Cupcake printer, to have at least some results with a 3D Printer this year ;-) Last week the package arrived and this week I started assembling the MB body.

Lost directions

Aaaaargh, finally found why the max stops didn't work, where they were dearly needed!
Escaped from Java Host to replicatorG and Eriks' 3D-to-5D script. Though building here sends all axis way beond the Max!
Anyhow, this is the code adjustment made in cartesian_dda.pde (svn #3252):

bool cartesian_dda::can_step(byte min_pin, byte max_pin, long current, long target, byte dir)
{
bool canStep = true; // 2009.08.27 JvO
//stop us if we're on target
if (target == current)
canStep = false;
#if ENDSTOPS_MIN_ENABLED == 1
//stop us if we're home and still going
if(min_pin >= 0)
{
if (read_switch(min_pin) && !dir)
canStep = false;
}
#endif
#if ENDSTOPS_MAX_ENABLED == 1
//stop us if we're at max and still going
if(max_pin >= 0)
{
if (read_switch(max_pin) && dir)
canStep = false;
}
#endif
// All OK - we can step
return canStep;
}

And next on the list is why the extruder stepper doesn't extrude. It does work in the stepperdriver test.

Infinite series and beyond

So spent again too much time on the FiveD Gcode and Java Host. For some reason the FiveD does see the MIN stops but refuses to recognize the MAX. Debugging the code gives me no clue whatsoever. Yeah, disabled the max stops.

Aside from the Mac Java Host stil failing with "gnu.io.PortInUseException", the latest Java Host (compiled with NetBeans) does not communicate with the FiveD properly. Despite tweaking baudspeeds and what not. The first command is sent and the next read returns "o" or "k" but no "ok". Maybe this is related to the Java Serial stuff. But why does the very same environment work well with the old GCode / Java host combination?

It's time to give RepRap the Java Host a break. In the meantime things may mature. Chances are I get an idea for the solution. But right now the Mac Intel, Java, NetBeans, Arduino, C-code, G-code, Extrusion, Heater construction and so on is too much to chew. It spoils my temper. True though, I learned a lot.

So that's it for now.

Arduino Serial monitor and carriage returns

Struggling to get the latest Java Host to talk to the firmware I checked the FiveD Gcode using Arduino's Serial Monitor. It failed the test and then I spent quite some time hours on this to learn that the Serial Monitor does not send the carriage return at the end of the line. Google turned up this Bitlash readme document. Bitlash being another project using the Arduino platform.
As a work-around, tweaked the firmware process_g_code:

// Get a command and process it
void get_and_do_command()
{
//read in characters if we got them.
if (Serial.available())
{
c = Serial.read();
#ifdef JVO_CR_DOT
if(c == '\r' || c == '.')
#else
if(c == '\r')
#end if
c = '\n';

Example of how you can test the firmware by entering the appropriate command, terminated by a dot, in the Arduino Serial Monitor:

M105. ; read the temperature
G1X10. ; position X
G0 X-99. ; X go home
G0 X-99. ; Y go home

See the RepRap wiki for more on G-Codes.
The minimum stops are seen now, for the maximum endstops I have yet to find out why these are not seen by the FW.
To conclude today with the reassuring (?) knowledge that the firmware seems to be ok so the Java Host is next in line.

Nanotec stepperdriver breakout

Hm, the glorious extrusion turned out to be unsustainable. Unreliable at the best. Hence preparing for the last resort,the pinchwheel drive.
Now working on a small breakout board for the Nanotec microsteppercontroller.

For those interested, you can download the Eagle files (beta version) (If you don't use stripboard, remove the holes and move all top tracks cq wires to the bottom layer, or ripup and autoroute all over again).