Sunday, January 27, 2008
Building a wall
Yesterday, I built a wall. Two in fact. This doesn't have anything to do with the reprap, except that now I'll have an actual workshop to work on it in, and now I won't have worry about kids pulling a shelf down on themselves in the food storage area. Since it now has an actual door. That actually locks. And that opens and closes! So that's a major accomplishment. With luck, I'll get the other wall and door done this week, and be able to put some more work in on the reprap next saturday. I hope so, because I'm leaving for a week, starting feb 5th, and won't be able to do anything at all with it for a bit after that.
Monday, January 21, 2008
Timeout Errors with Host Software
This , this and this all seem to indicate that the hardware flow control issue is a decimilla design feature. It uses the DTR line for it's software reset, and so you cannot use hardware flow control with this board.
So it's not a flaw in the board. It may still be a flaw in how the firmware uploaded. This is the same chip that had a bit error, but it verified properly so that being the source of the problem is unlikely.
So it's not a flaw in the board. It may still be a flaw in how the firmware uploaded. This is the same chip that had a bit error, but it verified properly so that being the source of the problem is unlikely.
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.
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.
Subscribe to:
Posts (Atom)
