Variable feed rate

Hi Stewart,

while returning to milling after some quiet time, I always try to use the latest version and I noticed that the feed rate is divided by 2 while drilling along the sides of the holes. From my tests this seems to have been implemented in Kiri:Moto 3.9.
My main need is to drill rectangular mortises for louver jambs, the immediate consequence is a milling time raised by a factor 1.7 for the same part from 1h15 to 2h10. As I need to repeat similar millings many times, the overall time is raised by the same factor : I needed 2 days for a louver, I need now nearly 4 days :frowning:
I tried to revert to version 3.8, I’m not seeing this feed rate change so I’ll use this version for the moment. But I won’t benefit of the fixes and improvements of the next versions.

I understand that it’s a quality optimization, may it be possible to disable it and let the user assume between a better quality and a lower milling duration depending on his needs ? Either a new “Optimization” operation or something in the rough operation, like a “Variable feed rate” checkbox ? If it’s in a separate “Optimization” operation it can be globalized for all the feed rates, and new optimizations in the future may be grouped there.
Maybe it exists already or there’s some topic about this and I didn’t see them.

Thanks
Patrice

I don’t have a permanent solution to what you are seeing, but an easy workaround is to do a search and replace on you G-code file using a text editor. Search for the string Fxyz where xyz is the feed rate that is too low, and replace it with Fabc where abc is the feed rate you want.

Note that you should confirm that the change affects the code in the way you expect, but in most cases it is, and is a pretty simple change.

Hi Jeff,

thanks for the idea, sorry for being long to answer, I’ve been off for a while.
Examining more closely the generated nc files, I saw that the value to replace is always at the end of a line and followed by a newline (\n). Then I have to search for an F followed by digits, a \n i.e. a whitespace-looking character, and the end of the string. I’m a Perl user, here’s a simple implementation with Perl in two steps, the first one is optional if you already know the value to replace.

  1. find the value to replace if you don't know it : it should be the most frequent in the nc file. The left column of the output contains the speeds, the right one the number of occurrences.
    perl -MData::Dumper -ne '++$h{$1} if /F(\d+)\s/ ; END { print Dumper(\%h) }' your nc file
  2. replace in your file : -i is mandatory to replace in-place, or you'll get the output on stdout. If an optional dotted-extension is provided after -i (warning : no space between -i and the extension), the original file is first copied to fileoptional extension e.g. file.bak if you use -i.bak, then modified in-place.
    perl -ioptional dotted-extension -pe 's/Fspeed value to replace(?=\s)$/Freplacement speed$1/' your nc file

Example, the file to modify is a.nc :

  1. search for the value to replace :
    perl -MData::Dumper -ne '++$h{$1} if /F(\d+)\s/ ; END { print Dumper(\%h) }' *a.nc*
    $VAR1 = {
              '1100' => 453,
              '6000' => 9,
              '200' => 480,    this one is too low, it's not the one to replace
              '500' => 11,
              '550' => 480     the value to change
            };
  2. actually replace in-place with a backup of the original file in a.bak :
    perl -i.bak -pe 's/F550(\s)/F1100$1/' a.nc

Nice use of perl, and thanks for posting. It is ideal for stuff like this, even though I use python more these days.