motion.adaptive-feed range problem

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?

use 'halui.feed-override pins' together with motion.adaptive-feed

I considered doing that, however the halui component runs on a much lower frequency that the motion component.
I am running a real time component that very quickly needs to change the feedrate. motion.adaptive-feed can do that, but only from -1...1 I cannot use halui.feed-override unfortunately because it would be too slow, not real-time like the motion component.

Some context here. The application is wire EDM. During normal cutting my software calculates the feedrate and controls motion.adaptive-feed to get the right speed, which normally lies in the -1...1 range of the feedrate. However, there are occasional shorts, for which the machines needs to retract fast in order to prevent wire breaks. Retraction is now performed at -1*feedrate due to the limitation. However this is not fast enough, I need that to be faster.

yes, just modified my comment to include the context

I'm afraid I'm not aware of a faster way to set feed-override than halui.
If you feel like experimenting you could try and remove the value clipping for 'motion.adaptive-feed' in 'src/emc/motion/control.c' (you would need to build linuxcnc on your local machine to do that though):

 

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.