Wednesday, May 05, 2010

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...

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
M104 S0

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.


Merlz said...

It looks like the bandwidth limit for commands is somewhere just above stepsize 1.0 - so commands are relatively instantaneous at this stepsize (due to the execution time of the step allowing the loading of more data).

I would suggest that maybe if there are some longer steps, you could jam a finite (probably calculable or measurable) number of shorter steps between them without slowdown. This could be tested by alternating between 20.0 and 0.1 step sizes (still averaging above 10.0 - so should be 75mm/s).

Thomas Charron said...

What firmware are you using? Some firmwares that was exactly the case, that the speed was that of the axis which had the longest distance to travel.

Forrest Higgs said...


c0527onniemcgehee said...


tim said...

"When it is running F960 seems to be the speed of traverse of the longest dimension {xy} of the print road."

That is exactly what you find in the firmware code for the Arduino based repraps (makerbot etc..):

The feedrate in that firmware is the speed of the axis that has to do the biggest distance in a particular move. The other axis moves slower of course, because the need to arrive at the same time.
So the xy speed would indeed be higher than the speed of the 'dominant axis'

You can see it when you download the stepper code and look at how dda_move() works.