[KwartzLab] 3D printer progress - August 2nd and beyond

[Kevin Martin]

I feel compelled to point out that the GCode interpreter in the Mendel seems to treat the F (feedrate) word in a non-standard way, and the GCode generation in the app we have been using assumes (and makes uese of) this non-standard interpretation.

The standard interpretation of the F word is that it should be the desired feed speed for the entire move, and that the GCode interpreter will handle the acceleration limitations itself (so the move may start off slower than what the F word specifies, and may also slow down at the end if the next move is unknown or causes an inflection point. A move command lacking an F word will use the same feed speed as the previous move.

The nonstandard behaviour in the Mendel motherboard firmware is that if the F word appears on a G01 (linear move) command which also moves the cartesian location, the Mendel also does interpolation of the feed speed between what it was at the end of the previous G01 (for the start of the move) and the value declared in the F word (for the end of the move). I am not quite sure if the feed rate interpolation is based on distance already traversed (which would actually give speed and position exponential in time) or based on time since the move began. The generated GCode seems to use this to generate acceleration envelopes.

Mind you I can't track down chapter and verse that the former is "standard" and the latter is "non-standard." My Machinery's Handbook has a rather archaic description of GCode which doesn't really describe the true action of the F word for linear interpolation (G01) moves.

In any case this discrepancy may cause incompatibilities between GCode from various generators and the Mendel printer.

-Kevin Martin
 the Papertrail Handmade Paper & Book Arts
 New Dundee, Ontario
 518-884-7123
 www.papertrail.ca