Gscreen - a GTK / Glade / Python based screen

Hay Chris,

I have a slider on my gscreen_moccapy custom screen, and I am using also the slider from axis.
On one machine I have an Jog Wheel conected to halui.max-velocity

I pushed my screen to mah, if somebody want to test it, even is is not finished jet.

Norbert

tjamscad wrote: I added all 9 possible axis to Gscreen simulator and the text height is different after x,y,z.

Also the readout information is not center on the selection box. Can that be changed?

Yes it can but I may have a problem dealing with it.

Right now the INI file decides which and how many axes shows.
A different file, the screen's GLADE file (this defines that basic look and layout of the screen) sets the size of the text.

I'm pretty sure that if all the AXES show they will need to be with smaller text. I can't see a satisfactory way to do this automatically.
I say this because Gscreen works with other quite different screen files so I can't fix one and screw another up.

So what this might mean is you as the integrator may have to edit the GLADE file to adjust the layout for the particular machine.
It's not hard - just another step to learn - But let me see if I can get it to automatically figure it out first.

Chris M

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
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