Took a different work around / approach. Instead of requiring my customers to set a max expected feedrate in their G-code, my new feedback control will require them to always set the feedrate to F1000. This is then the highest feedrate used for retractions. My feed control component then does the scaling stuff and estimating the optimal FRO value. This works nicely.
I did run into show stopper performance issues after switching to 2.9.3 and bookworm, I'll start a new topic for that.
I guess I am a little late here, I apologize I received the email response from Rob Ellenberg a few days ago but couldnt get back to this until now. I didnt see your work-around before I pushed a commit (
github.com/LinuxCNC/linuxcnc/commit/0625...250a6cfb701303966f7e
) to the master branch to change this for you. It would allow you to set the range for motion.adaptive-feed based upon the ini file's MAX_FEED_OVERRIDE value. This was chosen to play nice with the trajectory planner.
I had noted the following in the commit, but for the sake of closing the loop here and for those who dont read the commit notes, here's what Rob had to say:
As best I recall, I was preserving the existing behavior (it was likely limited to [0,1.0] before). That said, I don't think there's a fundamental reason it can't be greater than 1, though you'll get suboptimal lookahead behavior if you make it greater than the max feed scale value defined in the INI file. The TP creates the blend arcs with large enough radii to be smooth at maximum feed override. If you made the valid range [-max feed scale, max feed scale], I think it would be safe.
Perhaps this is better than the work around you concocted?
