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 (https://github.com/hansu/linuxcnc/commit/4752890b0ea5cafd9d5e536346e0fc83c317382b)
• 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?

[Roguish000]

use case.... well, there are times I just want to slow things down, without re-coding. (changing g0 to g1 fx) also, I just scanned through both the html and pdf docs (dated 25 March 2023) for 'max_rapid' and did not find it...waz up with that? I have MAX_RAPID_OVERRIDE in my .ini file, [DISPLAY]. can't remember exactly where I got the line from, but almost certainly copied it from a doc or an example config..... wow, just checked the qtdragon_inch.ini example config, and there it is. Shouldn't every single parameter in examples (not user created parameters) be in the docs?
I strongly suggest someone review and document everything in the qtvcp, especially the examples that are apart of the source and .debs.

look at section 10.5.2.4 no rapid

is max_rapid_override a percentage of the rapid speed? or actual machine units per minute? proper docs would really be useful....

ya know, it would also be really nice to have the actual hierarchy of the speeds and overrides explained. there are linuxcnc motion speeds, joint speeds, axes speeds, gui speeds, overrides..... what are the rules...???? who's on top?

[c-morley]

MAX_RAPID_OVERRIDE could only limit the maximum possible override in the screen to less then 100%

We are NOT talking of getting rid of RAPID_OVERRIDE - only the INI entry MAX_RAPID_OVERRIDE. in which case the maximum would always be 100%

Qtvcp does not support MAX_RAPID_OVERRIDE that is why it was removed from the docs.

[SebKuzminsky]

This setting is used only by GMOCCAPY and SilverDragon. It is not documented anywhere. We (the 2023 Hackfest Issue Executive Review Committee) do not understand what its intended behavior is, and support your valiant effort to delete it.