motion.adaptive-feed range problem

More
11 Oct 2024 08:01 #311797 by BaxEDM
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?

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 09:12 #311801 by Aciera
use 'halui.feed-override pins' together with motion.adaptive-feed

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 10:59 - 11 Oct 2024 11:07 #311803 by BaxEDM
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.
Last edit: 11 Oct 2024 11:07 by BaxEDM.

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 11:03 #311804 by tommylight
Hi Bax,
Is this for the EDM's you build?

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 11:08 #311805 by BaxEDM
yes, just modified my comment to include the context

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 13:19 - 11 Oct 2024 14:20 #311808 by Aciera
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):

 
Attachments:
Last edit: 11 Oct 2024 14:20 by Aciera.

Please Log in or Create an account to join the conversation.

More
11 Oct 2024 13:37 - 11 Oct 2024 13:42 #311809 by snowgoer540
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.  
Last edit: 11 Oct 2024 13:42 by snowgoer540. Reason: Add info

Please Log in or Create an account to join the conversation.

More
13 Oct 2024 04:43 #311923 by cmorley

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.
 

Please Log in or Create an account to join the conversation.

More
13 Oct 2024 10:32 - 13 Oct 2024 10:37 #311944 by BaxEDM
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.
Last edit: 13 Oct 2024 10:37 by BaxEDM.

Please Log in or Create an account to join the conversation.

More
13 Oct 2024 15:31 #311977 by spumco
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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.096 seconds
Powered by Kunena Forum