Feature request: rapid and feed override.

Currently we can do maximum velocity and feed override in gmoccapy. I would prefer rapid and feed overrides instad of 'maximum velocity'. Makes more sense than maximum velocity too if you ask me.

Some materials such as stainless steel need a steady cutting speed, but at the start of the program you do want to start with a slow rapid speed to see if the mill actually does what it is expected to do.

HalUI supports this, so it is possible.

I am not in desperate need for this, but if nobody ever asks...

It is allready in the code, just at the moment it is commented ouf.
I tested it and do work fine and smooth. I just do not know where to place a additional widget.

If you have any idea, let me know.
I can activate the code, so gmoccapy would react to the corresponding halui pin.

So the question is, what to do?

Norbert

Having the pins available is already much better than nothing (halui doesn't always cooperate with gmoccapy), but without feedback on the screen this is still less than ideal.
However; I never tried it but I think that adding a gladevcp panel at EMBED_TAB_LOCATION = box_vel_info can easily give anyone what he needs when the pins are available, so they are useful anyway.

My personal opinion is that 'maximum velocity' is a waste of screen space, and that screen space is used much better for a rapid override. If I set maximum velocity low to be able to react quickly enough when something unexpected happens at the start of a program, jog speed and feed suffers too. And if you have a rapid override, you also have maximum velocity control since you can control feed, rapid and jog speed.

Maybe this would work:
- Exchange maximum velocity for rapid override.
- Add a checkbox in settings to link the feed/rapid override sliders together. Thus when one is set to 50%, the other does 50% too. Then one external knob or only half the mouse actions can be used to scale down program execution speed while keeping jogging speedy.

Of course you can also make it a setting whether the user wants rapid override or maximum velocity control.

the okuma lathe I used would make rapid override active only when in single-block mode.
So in single-block mode the feedoverride knob changed feed rate and rapid override.

I liked it. I've never liked max-velocity override but ...may ways to skin a cat.

Chris M

Is this fool-proof in the trajectory planner to issue FRO in running G-code?

Interesting question.

Personally I don't think that the segments in the queue are recalculated when someone overides the feed. I also never noticed the slowdowns associated with queuebusters.
If the segments are not blended again, increasing the feed override to above 100% might cause a temporary acceleration limit violation in corners. But that is only speculation.

Feed overrrides below 100% only slow things down, nothing is violated.