motion.adaptive-feed range problem

I wonder if there was a functional reason this was clipped to +- 1?

Edit:  I’ll reach out to the author for that commit and see if I can get an explanation.  The commit details explain the negative stuff, but no reason as to why 1 was choosen in either direction.  

BaxEDM wrote:

Hi,
I am using the motion.adaptive-feed to control my feedrate. The linuxcnc manual states:
"When adaptive feed is enabled with M52 P1, the commanded velocity is multiplied by this value. This effect is multiplicative with the NML-level feed override value and motion.feed-hold. Negative values are valid and will run the G-code path in reverse."

While trying this out, it only seems to work for the range -1...1 any values above or below that are clipped to 1 or -1.

I need to be able to set the value to greater than -1, e.g. -10 or greater. Is this possible and how can that be done?
 

You could set your programmed feed rate to double and set adaptive feed to .5, then you could ramp up and down in feed rate.
 

Yes, I considered that too, but that is a work around not really a nice solution. For instance I want my customers to be able to set a feedrate which makes sense, e.g. that is in the same order of magnitude as the actual expected cutting rate. However the incidental retracts need to be much faster.
The workaround approach would then be to set the desired feedrate two orders of magnitude greater that the expected feedrate, just to cope with the -1...1 limits of motion.adaptive-feed. Doable but not intuitive for my customers.
Also, setting the feedrate two orders of magnitude higher than the expected feedrate requires modifications to my feedrate control loop depending on the material and thickness. This would require an additional dail for my customers to tune, I do not want that. The simpler the better.
Up until now I managed with the -1...1 limits, but I think the control can be much better without them.

Refining @cmorley's suggestion...perhaps you could use two scale components to manage the adaptive feedrate.

Step1: scale.0.gain => programmed feedrate down to -1/+1 range
Step2: feedrate adjustment based on arc voltage
Step3: scale.1.gain => back up to desired output

The operator/programmer, as well as your control loop, wouldn't see the backstage math fiddling.  I know it's not 'elegant', but should be easy to do in HAL until someone can edit the adaptive feedrate programming.

or set feed override to 200 %..then the feedrate setting could be nominal and adaptive would be .5 for nominal feedrate (I think)

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.