Sunday, January 20, 2008

Darned bit errors!

See my earlier post on the reprep forums for why I'm swearing at java. Use python instead!

After reinstalling Debian, I now have a usable computer again, and the reprap host software still didn't work. So I set out to write a G-Code interpreter for the Arduino. Or at least something that I could connect to with minicom and type at to test my stepper control and so forth.

That worked fairly well. I started with Zach Smith's SNAP arduino code for the reprap. I ended up throwing away almost half of it (went from a 12K build to a 8K build) and added fixed point arithmetic, axis control via a 3D version of the bresenham line drawing algorithm, aborting a line of input, parameter setting for the steps/mm setting (per axis) and was just about to test the "F" word (that's feed rate, get your mind out of the gutter!) when an upload of the firmware gave a bit error.

This part is rated, according to the data sheet, an 10K erase/rewrite cycles. I swear I didn't get anywhere near that. But there it is. Must be a bad chip or something.

So now I'm dead in the water until my chips come in. I ordered three atmega168-20PU's 'cause if it can happen once, it can happen again.

Today I figured out why the j3d library wasn't there, even though I put it into the right /ext directory. See a description of the problem. Many thanks to Stephen George for posting that! And to reece.arnott for figuring it out and telling Stephen about it.

Now that I can run the official reprap host software, I don't have to finish the G-Code firmware, though I'll probably do that anyway. I modified the Zack's firmware just enough to make it drive my steppers, and it doesn't have that particular bit set! JOY!

But it still doesn't work. I think that it may be becuase of a hardware problem with the USB serial port emulations Modem Ready signal not getting through. When uysing minicom to communicate with my g-code firmware, I had to turn off the "hardware flow control" which I would assume would use the modem's version of the DTR (Data Termial Ready) line. Otherwise nothing was actually sent to the arduino. That might be a flaw in the hardware, or something funny about my decimilla, as opposed to a standard feature of the decimilla. I don't know enough to say.

I'll research that later.

0 comments: