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.

tecno wrote:

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

Not sure what you mean. Feed Override is _for_ adjustments to running gcode.
The planer will not violate speed and acceleration limits on override adjustments if correctly set up.

Chris M

OK, you all convinced me. I will change max-velocity slider to be rapid-override.

As gmoccapy 2.0 is comming closer, I will indroduce the change with the new version and leave all gmoccapy 1.XX versions unchanged.

Something more you would like to change?
If it was only me, I would change some hal pin names to collegt them in groups, all jog hal pin in a jog group etc, but I am affraid to destroy to much configs with such a change.

Norbert

Hmm, let me think...

- When I try to jog when MDI mode is selected but the machine is idle, I get the EMC_BLABLA error 'cannot do that'. Quite irritating; when positioning I use both MDI to go to known coordinates (e.g. G0 X0Y0 to position the mill in the XY plane) and jogging (to find the Z height for touchoff when I cannot use the probe, for example).

- In settings 'Apearance' is written wrong.

- Clicking on the DRO to change to absolute/DTG mode is irritating; I never do that on purpose, only by accident. Gmoccapy already shows the absolute and DTG numbers. I would like to have a setting to only have one of the relative/absolute/DTG modes displayed, plus homed/not homed.

- Editing the tool table needs some getting used to. You need to check the box in front of the tool you want to edit, click on the field, enter a value, and then you HAVE to press enter otherwise it is not remembered. And then there is the 'apply' button; if you forget to press that one and go to another screen (to see the DRO for example) and back the changes are lost.

- This is more a LinuxCNC than a gmoccapy issue and certainly not something you can solve alone: people visit my place and see a kitted out LinuxCNC installation with probe_screen, features, etc. They see me entering some numbers, mount a block of material, a lot of noise and a few minutes later, presto, bracket is ready.
Now they think 'Wow, great!', they download and install the Wheezy ISO, and are stuck with a very basic Stepconf generated AXIS setup that can only load a file and play it. Every single user has to scrape the components together and integrate them to have a more useful CNC control.
Maybe it is time to integrate a few of these externals. You more or less did that with tool measurement too. Probe-screen is a good candidate, as well as features or ngcgui. That allows people to actually do something with the software after installing. If someone doesn't need it then that tab simply isn't used.

- When I try to jog when MDI mode is selected but the machine is idle, I get the EMC_BLABLA error 'cannot do that'. Quite irritating; when positioning I use both MDI to go to known coordinates (e.g. G0 X0Y0 to position the mill in the XY plane) and jogging (to find the Z height for touchoff when I cannot use the probe, for example).

I hate this behavior from linuxcnc too!, but it is not gmoccapy related. I am a little surprised that you get an error. Do you use the gmoccapy hal pin?

- In settings 'Apearance' is written wrong.

Will correct that and make it "Ausssehen"

- Clicking on the DRO to change to absolute/DTG mode is irritating; I never do that on purpose, only by accident. Gmoccapy already shows the absolute and DTG numbers. I would like to have a setting to only have one of the relative/absolute/DTG modes displayed, plus homed/not homed.

Took that to my to do list, to check if I can realize that with a settings switch.

- Editing the tool table needs some getting used to. You need to check the box in front of the tool you want to edit, click on the field, enter a value, and then you HAVE to press enter otherwise it is not remembered. And then there is the 'apply' button; if you forget to press that one and go to another screen (to see the DRO for example) and back the changes are lost.

I do agree 100 % with you, the tool table and tool editing is a mess! I would like to integrate a new "tool editing with moving through the cells with TAB, and add also wear offsets and some more stuff, like small images. Unfortunately, that is some coding work and due to gtk2 it is not as easy as I imagined, Just let me some new stuff for gmoccapy 3.0

Maybe it is time to integrate a few of these externals. You more or less did that with tool measurement too. Probe-screen is a good candidate, as well as features or ngcgui. That allows people to actually do something with the software after installing. If someone doesn't need it then that tab simply isn't used.

Yes, it would be time and linuxcnc-features is on the best way to make it. But we are very far away from a point and Click configuration system. I do not think, that that will ever happen, as linuxcnc offers to much possibilities to include all of them.
So feel free to make a schedule or a little sketch, "How should a beginner linuxcnc config be? We may then make such a sample config as start point and add later a GUI to set more parameters. Begin with the hardware, then the GUI, that the options etc.

Such a detailed documentation would be very helpfull.


Norbert