Remove MAX_RAPID_OVERRIDE

[hansu]

I do not see the sense of the setting MAX_RAPID_OVERRIDE. I assume rapid movements are done with MAX_VELOCITY of each axis. So if one axis is moved, the rapid velocity cannot be greater than its max velocity.
Only if multiple axes are moved simultaneously the resulting velocity can be greater.
Assuming a circle in the X-Y plane and a MAX_RAPID_OVERRIDE value of 1.2. This will lead to a varying rapid speed depending on the position of the circle. Is that a desired behavior?

Currently only gmoccapy and gscreen seem to use this value. Furthermore it is present in many qtdragon sample configs. And it is not documented.

What is your opinion about that?

[c-morley]

I wrote this thinking you were referring to rapid override it's self - now I think you meant just the setting MAX_RAPID_OVERRIDE.

answer for that:
I agree, it's a limited use case - it can only lower the rapid limit.
If you feel strongly on removing the MAX_RAPID_OVERRIDE setting, I could live with that :)

Previous answer:

Rapid override is a common control on industry standard cnc machines.
Machinists will expect and be familiar with it.

Linuxcnc approximated this behavior with max velocity. Later we added rapid override.
Some people prefer, or are satisfied with, max velocity.

MAX_RAPID_OVERRIDE can only be set as high as 1.0
If in fact it is not super exact in it's speed setting is not important in use.

Qtdragon does use rapid override. I will add to the docs - thanks.

[c-morley]

After all that I looked in Qtvcp's code and in fact max rapid override is assumed at 100%
So I'm behind in my own code ! lol
Thanks for the realization. I will remove MAX_RAPID_VELOCITY from QtDragon.
I also see that it was set at 1.2 which is impossible anyways, so again thank you for bringing it to my attention.

[hansu]

I played a bit around with Gmoccapy and Axis which confirmed me that rapid movements are carried out with the max velocity of each individual axis.
For example:
G0 X200 --> 9960 mm/min
G0 X200 Y200 --> 14040 mm/min
So a rapid override > 1.0 and therefore a MAX_RAPID_OVERRIDE setting makes completely so sense here.
Also interesting to notice that an override value of 1.2 lead to a possible rapid override of 150% in Gmoccapy :D (which has no effect).

If you feel strongly on removing the MAX_RAPID_OVERRIDE setting, I could live with that :)

I would like more that you are happy with that ;-)

Rapid override is a common control on industry standard cnc machines.
Machinists will expect and be familiar with it.

Rapid override for reducing the rapid velocity is an important feature that I won't miss, without question.

Thanks for the realization. I will remove MAX_RAPID_VELOCITY from QtDragon.

I think it can also be removed from the woodpecker configs as they are QtVcp based, right?
And qtdragon_xyza slipped through I guess.

[c-morley]

I am happy to remove it. I fixed the woodpecker and missed qtdragon. thanks.

[hansu]

I thought a little bit about that and came to the conclusion that the setting MAX_RAPID_OVERRIDE might make sense if used to decrease the max rapid velocity. I have no use case for that but that gives you the freedom to define the end of this override slider like for feed override.
So for consistency reasons I tend to let it persist but limit the max. value to 1.0.

[gmoccapy]

I do use rapid override just to test programs. I.e. A very complicated program, but I am not sure, if the machine can pas every object, like Chuck parts etc. So I reduce max rapid overide, but feed overide will remain 100 %, as I do not want to reduce the cutting parameters.

So in fact it makes sence.

Norbert

[hansu]

Sure, rapid override for reducing the rapid velocity is an important feature that I won't miss, without question.
But this issue is about the upper limit of this override.

[gmoccapy]

Sorry, I missed that.
Rapid Override does not need any upper limit, as it is 100 % and how to travel fast than with max feed?

Norbert

[hansu]

Exactly that is the point. So that's why I first thought that setting is unnecessary.
But one can use that setting to limit the rapid velocity to, e.g., 0.8. Does that make sense for you?

[gmoccapy]

No, setting this to 0,8 makes no sence IMHO, as in that case the user can set the max velocity lower in the INI file.

[hansu]

Then the setting MAX_RAPID_OVERRIDE is unnecessary. Do you agree?

[hansu]

No, setting this to 0,8 makes no sence IMHO, as in that case the user can set the max velocity lower in the INI file.

Only if a user wants to limit the rapid velocity but wants to jog with the max speed of the axes. But that's weird - who would do that?

[hansu]

Currently the behavior in Gmoccapy is the following:
When MAX_FEED_OVERRIDE or MAX_RAPID_OVERRIDE is set to a value < 1.0, then the override-sliders shows those reduced values, but the override-rates are not according to the sliders.
Two possibilities:

• Apply the values after loading the settings (hansu@4752890)
• Set the lower limit to the max override values to 1.0 and display a warning when a lower value is found in the INI file. Because It does make completely no sense for me to not be able to select a feed/rapid override value of 1.

What do you think @gmoccapy ?

[Roguish000]

Gentlemen. I like the MAX_RAPID_OVERRIDE. I use it..... please leave it.

[c-morley]

Can you explain the use case?