Feature request: rapid and feed override.

newbynobi wrote:

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?

Yes:

..
# MPG buttons to gmoccapy jog
net jog-x-plus xhc-hb04.button-macro3 => gmoccapy.jog-x-plus
net jog-x-minus xhc-hb04.button-macro1 => gmoccapy.jog-x-minus
..
..

It should not be too hard to rig a few HAL-components together that switches from MDI to manual mode when needed. I just did not do it yet.

and make it "Ausssehen"

Fine with me!

Just let me some new stuff for gmoccapy 3.0

Do you want us to keep nagging you that long?

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.

Maybe it is not a gmoccapy thing, but more a stepconf/pncconf thing. Once you do not need those anymore you are probably capable enough to spice up your configuration to your liking. The problem is the beginner that uses stepconf.

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.

Hmm. Hardware is easy; 'everybody' starts with stepconf or pncconf, so imho that part is covered.
But once stepconf is finished, you would like to actually do something with the software, and that is not really possible. You cannot mill a single hole or turn the outside of a piece of stock to diameter. Most other software has wizards for simple tasks.

So what would I prefer? Something like linuxcnc-features (or ngcgui; that's already in the distribution) and probe_screen integrated in a few tabs. There is no reason why 'user tabs' should be user tabs only, and if somebody does not use it they are not in the way either.

But the more I think about it, the more I think it is really a stepconf/pncconf issue.

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?

Yes:

..
# MPG buttons to gmoccapy jog
net jog-x-plus xhc-hb04.button-macro3 => gmoccapy.jog-x-plus
net jog-x-minus xhc-hb04.button-macro1 => gmoccapy.jog-x-minus
..
..

I got the bug, it is caused when releasing the button, I missed to check for Manual Mode, will correct that.
And I will try to allow Jogging in MDI Mode, but that could cause some deeper changes.

Norbert

Appearance typo and jog-error message is fixed in 2.6 / 2.7 and master.

Norbert

Nice! I will pull a fresh copy of master somewhere this week.

Jogging in MDI would be nice, but something like 'if (jog-* == active && current_mode != MODE_AUTO && current_mode != MODE_MANUAL) change_mode (MODE_MANUAL); ' would do too, so the time being.

A nice solution would be far more complex, and usually evolution wins it from revolution.

@DaBit,

unfortunately that is not so simple. I could make that change with a few lines of code, but I do not know how that will take influence if you use a MDI command from your own button, or if you use MDI_COMMANDS from the INI file. And there are some more ways to execute a MDI command. So there might be a lot of situations to take care of.

But I will not forget about that.

Norbert

The problem is the unability to jog when the machine is idle, unless you are in a specific 'manual' mode. That is a different thing than executing MDI commands (strangely enough you can execute an MDI command through halui or something when the machine is in manual mode, so the mode dependancy is not even consistent).

Basically I would want to be able to jog the machine whenever the trajectory planner is idle. This is slippery territory, but being able to jog when a running program is paused (and therefore the TP is idle) is a useful thing too imho, for example. Things are about to go wrong, pause, jog up, inspect something, clear some chips or whatever, jog down, continue. It might also cause problems because the subsequent program move is not the intended one, but if you screw things up that's your responsibility.

I personally hate it when software tries to make things idiotproof by just not allowing actions. It doesn't even work, because when you make things idiotproof someone just proves himself to be a better idiot and everybody else is left with 'I want to, but they won't allow me..'.
I still want that 'shut up and just do what I ask you to do' button in Windows too, for example

@DaBit,

i mostly agree, but jogging while paused is dangerous! If you want that feature, you can include it with the moveoff hal comp. It does work fine.

Let me see what I can do with jog on MDI, I have a idea to make a work around, I will contact you if I am ready for tests.

Meanwhile I have added the option to disable DRO Mode change with a click oin the DRO, just see the doku in 2.7 branch or just on the settings page. It is included in release 1.5.6

Norbert

I do not expect anyone to fully agree with the previous post. There is a lot of personal opinion in there.

Life is a bit busy at the moment, but I will pull a fresh copy from master on the mill somewhere this week; that will give me the new gmoccapy. The lathe stays at 2.7.3 until everything else has stabilised (build is not finished yet).

In my opinion will be great, if there is the possibility to set and switch the velocity between mm/s and mm/min.
It depends by the application. In our case, we adopt this GUI for 3d printing, and so in this field is mostly used mm/s.
At last, due to the fact that I'm not a great designer. There is a way to add the temperature setting and measuring of the extruder and heated Bed with the same design of the feed override/Max velocity?

In attached my actual first attempt but it's not like the rest of the GUI.

Thank you in advance

Halo Alesandro,

it has allready be done
I do hope you know Spanish, as this page is in that language.
There are several parts explaining the possible changes of gmoccapy.

Norbert