motion.adaptive-feed range problem
11 Oct 2024 08:01 #311797
by BaxEDM
motion.adaptive-feed range problem was created 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?
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.
11 Oct 2024 09:12 #311801
by Aciera
Replied by Aciera on topic motion.adaptive-feed range problem
use 'halui.feed-override pins' together with motion.adaptive-feed
Please Log in or Create an account to join the conversation.
11 Oct 2024 10:59 - 11 Oct 2024 11:07 #311803
by BaxEDM
Replied by BaxEDM on topic motion.adaptive-feed range problem
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.
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.
- tommylight
- Online
- Moderator
Less
More
- Posts: 19188
- Thank you received: 6430
11 Oct 2024 11:03 #311804
by tommylight
Replied by tommylight on topic motion.adaptive-feed range problem
Hi Bax,
Is this for the EDM's you build?
Is this for the EDM's you build?
Please Log in or Create an account to join the conversation.
11 Oct 2024 11:08 #311805
by BaxEDM
Replied by BaxEDM on topic motion.adaptive-feed range problem
yes, just modified my comment to include the context
Please Log in or Create an account to join the conversation.
11 Oct 2024 13:19 - 11 Oct 2024 14:20 #311808
by Aciera
Replied by Aciera on topic motion.adaptive-feed range problem
Attachments:
Last edit: 11 Oct 2024 14:20 by Aciera.
Please Log in or Create an account to join the conversation.
- snowgoer540
- Offline
- Moderator
Less
More
- Posts: 2388
- Thank you received: 779
11 Oct 2024 13:37 - 11 Oct 2024 13:42 #311809
by snowgoer540
Replied by snowgoer540 on topic 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.
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.
13 Oct 2024 04:43 #311923
by cmorley
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.
Replied by cmorley on topic 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?
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.
13 Oct 2024 10:32 - 13 Oct 2024 10:37 #311944
by BaxEDM
Replied by BaxEDM on topic motion.adaptive-feed range problem
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.
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.
13 Oct 2024 15:31 #311977
by spumco
Replied by spumco on topic motion.adaptive-feed range problem
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.
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.106 seconds