Gscreen - a GTK / Glade / Python based screen

cmorley wrote:

tjamscad wrote:

cmorley wrote:

tjamscad

re F0 S0 and V0

I was thinking you were talking of the overrides in the status window.
Maybe you were speaking of the Gcodes active window?

You are correct, Feed and Spindle override normal but the "VO" is for velocity override correct? Wich in turn makes it Rapid Feed Override?

Sort of - VO limits the maximum speed of ALL moves. So if you turn down VO below a feedmove speed it limits feed moves too.
I am not sure this is how industrial machines work, but there is little I can do about it - that's how linuxcnc does it.
My only reference was the Okuma lathe I ran - it turned both feeds and rapids down at the same, so at 50% the feed was at 50% and the rapid was at 50%.

Anyways that's why I chose VO rather then RFO or RO - I could change it to RO if you think that's fine.

Chris M

No better leave it as "VO" since it is really not a rapid feed move. The guys in the shop think it is. Maybe it is better to not have it shown since it does not function like one would think.

Did you see the things that Stuart is inquiring about?

cmorley wrote:

tjamscad wrote:

When in set override mode, changing jog speed using the + and - seems to work. Set at changes to 5.1 IPM Zero seems to work. Am I useing the "Set at" wrong?

well if the upper right entry widget said 5.1 (or more likely 5.125 I limited the jog rate to 1 decimal) then it worked right.
But it would probably be better to have a pop up number entry. - I may in fact be able to get rid of that entry widget if I did that for all entry points.

That was it. I had now idea that was even tied to anything. Perhaps giving it a title?

tjamscad wrote:

Chris,

Stuart has some ideas and questions. Can these things be done with Gscreen or is LinuxCNC not capable yet? I think you have taken care of some of this already.

1. motion during feed hold to allow tool change and reset and/or manual cutting to facilitate further gcode motion

2. incremental offset adjustment (possibly a .ini file choice)

3. rigid tapping using the handwheel (handwheel driving spindle and axis following?)

4. five axis cutter diameter compensation

5. dead simple - absolute reliable program restart on a line (this should read all code up to the start line and move to the position commanded in the restart line and continue on as if the program had been running uninterrupted from the start.
The Haas machines do this now.

6. the ability to back up through the program and have the machine follow the path in reverse

7. the ability to probe parts to establish work piece coordinates and automatically write to the vars

8. the ability to probe an artifact and calculate the necessary compensation values to correct the machine motion in the control
The Fadal machines with scales do this using a routine to compare ballscrew motion with the scales on the machine axes and writes to the comp tables to correct the ballscrew positioning to the scale. The Fadals with scales do not use the scales during operation but only during the cycle to determine the comp tables.

9. the ability to use absolute position feedback devices"

1) no, but the principal was proven workable by a developer named Michael - there is a Utube example.
not sure why he didn't add it to master but he is pretty active in reorganizing linuxcnc reatime stuff right now.
2) Do you mean wear offsets like for a lathe? There was a patch for that wear offsets and lathe like tool changes (no M6 needed)
there was some work to do on it yet so was not added.
If you mean incremental like in add .002 thou to this tool with a button push. linuxcnc does not support that.
I could add facility to do something like that, but it would not be able to keep a separate table of incremental offsets.
3) no, But I don't think that's impossible to add - but it's above my pay grade.
4) no, that's a big chunk of code to work on and only a couple people understand it enough to even try. I can't speak to what would motivate them.
5) Well i have been told a screen called Mocca did something this this. Not sure if it was dead reliable or not. (Mocca is not included in linuxcnc, so has limited user base) I am interested in looking at the code but it's written in an unfamiliar language to me, so would take some time to decipher I think.
6) no
7) pretty sure it can - there are probing routines and Mocca
8) I bet this could be done
9) yes and no I don't think using an absolute encoder is much of a barrier, the problem comes to homing. Homing is hard coded to change the reference point to zero rather then a arbitrary absolute value ( a simplified way of looking at homing ) and of course linuxcnc expects to home when
started. If you have absolute position available at start up - linuxcnc wouldn't understand you don't need to home and wouldn't automatically reference to the absolute position. I would guess this is medium complexity to add.
I would like it too - I have some scales with distance coded indexes that could be used to home by moving a small distance, starting from an arbitrary position.

tjamscad wrote:

When in set override mode, changing jog speed using the + and - seems to work. Set at changes to 5.1 IPM Zero seems to work. Am I useing the "Set at" wrong?

Chris,

I ran into this today on the mill. When in Set Override mode, pressing "Set at" seems to be able to set any of the overrides. I think this might be dangerous. I got a surprise when I pressed "Set At", and it set the jog increment to 0.3 inches (what spinbox happened to be). I don't think it should be allowed to set the jog increment, but what do others think? Should it be able to set the other overrides?

Karl

Well I'll defer to consensus about whether it should be allowed.

but if it popped a dialog (with 'override' title) it probably would have been more obvious yes?

Chris M

Hi Chris,

I have been quietly using Gscreen and so far the suggestions that you have incorporated have been great. I am especial thankful for the Velocity readout you have currently added.
The only thing I'm missing for my setup is a Jogspeed display but I will look at adding this once development slows a little, that is unless someone else adds it first ...

Thanks,

Jayson.

Jayson

Thanks for letting use know things are well while using Gscreen.

Jog speed display do you mean current jog rate or current velocity while jogging or something else.

Cause both of those are there.

Chris M

Well that's good to hear, I just need to look more closely
I have one of my dials linked to halui.jog-speed to set the speed the axis will move at when I hold down one of the physical jog buttons.
I think this will be useful on my machine to use it in manual mode for facing operations and such.

Thanks,

Jayson.

ahh that's what is going on. Gscreen can't get the jog rate from HALUI.
So Gscreen just report the jog rate that was set in the INI file or some default in Gscreen.

Funny i was just trying to remember this problem when talking to Chris Radek today...

cmorley wrote:

Well I'll defer to consensus about whether it should be allowed.

but if it popped a dialog (with 'override' title) it probably would have been more obvious yes?

Yes that would have been fine.

A couple more questions about jog increments.
1. When set to continuous, gscreen.jog-increment.out is zero. This essentially disables the panel-mount jogwheel, because it uses the increment from gscreen. In our setup the MPG uses its own set of increments so it still works. How about if gscreen.jog-increment.out used the largest jog increment if continuous is set. I wonder if others would use a similar setup, and have any comments about this.
2. When touching off the work or a tool, we normally start with the largest jog increment and then go to lower increments as we get closer, winding up with a 0.0001" increment. It's a bit cumbersome to go into Set Override mode to change the increment and back out to change the axis.

Any thoughts?

Thanks.
Karl