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.

Further tests

I did a very careful, new series of speed tests using F960 (16 mm/sec) over a much longer diagonal baseline, viz, 1.7 meters, with the extruder running.

Here's what I found...

Step (mm)    Seconds (s)    Velocity (mm/sec)

    0.1                214                   5.77
    0.2                110                 15.40
    0.3                121                 14.14
    0.4                  80                  21.21
    0.5                  80                  21.21

Note that...

21.21 mm/sec ~ 16 mm/sec x 2^0.5

...which is about what you would expect for firmware that didn't correct for the angle of the print road.

As you can see, the break comes between gcode distances 0.3 and 0.4 mm and is quite abrupt. This means that the vectorization routine for Slice and Dice can be quite crude and work well with Rapman.

What does F960 really mean?

The vectorizer in Slice and Dice is pretty inefficient. With certain slopes and curved surfaces I'd noticed that the print head velocity could drop by as much as 25% down from 16 mm/sec to 12 mm/sec. I'd spent the last weeks working on improving my vectorizer when it occurred to me that I really didn't know how much improvement I needed to make on it.

To sort that out, I did a series of test runs where I moved the inactive print head from x = -75 mm to x = 75 mm using different steps with the nominal head speed set to 16 mm/sec (F960).  Here are the very strange results that I got.

     Step (mm)     Seconds (s)     Velocity (mm/sec)

         0.1               25                         6
         0.5                 5                       30
         1.0                 3                       50
       10.0                 2                       75
     150.0                 2                       75


As an example of the gcode I used...


G90
G21
M103
M105
M104 S0
G1 X-75.00 Y0.0 Z20.0 F960
G1 X-74.90 Y0.0 Z20.0 F960
G1 X-74.80 Y0.0 Z20.0 F960
....
G1 X74.70 Y0.0 Z20.0 F960
G1 X74.80 Y0.0 Z20.0 F960
G1 X74.90 Y0.0 Z20.0 F960
G1 X75.00 Y0.0 Z20.0 F960
M103
M104 S0
M103

I did further tests and discovered that unless the extruder is running the extruder head speed defaults to 75 mm/sec.  When it is running F960 seems to be the speed of traverse of the longest dimension {xy} of the print road.

Specifically, I ran a 150 mm diagonal and discovered that F960 {16 mm/sec} clocks in at about 23 mm/sec.  when you divide 23/2^.5 you get right at 16 mm/sec which means that the traverse speed for the x and y axes, which with a diagonal are equal, is 16 mm/sec.

BTW,  I've started getting an SD Error2 report at the end of one of these test runs.  I'm not at all sure what that is all about.