Sunday, May 09, 2010
Processing gcode instructions with the Rapman firmware
After running a variety of speed tests with the Rapman, I gained enough data to estimate the processing time for two kinds of gcode statement. The G1 statement processes in the Rapman 3.1 firmware at a rate of 17 msec/instruction. M108 instructions process at a rate of 19 msec/instruction.
Interestingly, the rate for the M108 instruction is actually significantly longer than for the G1. Given the floating point instructions necessary to interpret a G1 instruction this seems very odd. It would seem that much more time is spent reading off of the SD card than processing the information on a line of code. Either that or carrying out a M108 instruction in the Rapman firmware is more complicated that it would appear at first glance.
As a practical matter what this means is that if one wants to print a layer with 0.1 mm print road lengths you are looking at a maximum print speed of around 5.8 mm/sec. A print speed along a long road component axis of 16 mm/sec would imply that your average road segment would be no less than 0.3 mm.
Subscribe to:
Post Comments (Atom)
5 comments:
is this linear when it's applied to more than one command ( ie 2 commands take twice as long, 4 commands 4 times as long? ) this is a lot of buffering in the USB protocol, such that a worst-case scenario with less than 64bytes of data can take 16ms to transmit to the arduino... but only when using small amounts of data and not filling the transmit buffers ( which are flushed WAY quicker when there is more than 64bytes of data to send ). Also, that doesn't even take into account any bfering that is happening in the arduino itself ( many firmware/s have them, not sure of the rapman)
Buzz.
Rapman uses a 32 bit Pic mcu, not arduino. It also reads off of an SD card, not USB. Same sorts of problems, though.
That sounds like an awful long time to spin for a simple operation.
Have you made any further diagnosis to determine where the time is being spent? Is there any sort of fast clock register you could use? With a little adaption, you should be able to create a few variables that you can dump timing information into to get where most of the time is being spent (be it floating point, card reader, etc.)
I'm not interested in doing a bunch of firmware upgrades on the Rapman. The people at BitsfromBytes take suggestions and complaints very seriously, so I suspect that they'll be looking into this pretty quickly.
And here is a proof http://www.flickr.com/photos/prusajr/4654375358/ comparing of toooo much detailed object with adequate one :-)
Post a Comment