Gscreen - a GTK / Glade / Python based screen

andypugh wrote:

cmorley wrote:

Thats another hard one to fix reliably. I could add this to my widget and fake it to linuxcnc, but it would be easy to write a program to break it, which would not be fun! We need linuxcnc to understand the concept of wear offsets. Nobody I know of is working on that.

I said I was going to look at the tool table, and that is part of that.
I haven't even started yet, though.

Andy,

What is on your list while looking at the tool table?

Chris,

Just for encouragement I downloaded Mach3 and ran it in demo mode. I think it has more features that are part of its base that LinuxCNC doesn't have yet. However the interface and I tried several made it cumbersome to use. Great work with gscreen!

cmorley wrote:

tjamscad wrote:

3. There some type of signal showing when each axis is homed?

I'll look into that - color change is popular or an asterisks

4. In the field showing machine position I like to see a 'distance to go' for each axis? Could you move the graphics screen to where the position is and the position stuff to where the graphics are now. That would make more room for the position information for the DTG and more than 3 axis's. Plus since you have the full graphics button you dont nessarly need a large graphics window.
Perhaps maybe remove the graphics window and make it show like the "display aux screen" under preferencs.

I assume from your discussions that your machinists don't care much about the graphics. I agree it would be much more useful if it could
pre-run the program without moving the machine.Having the graphics pop up as a separate window is not very practical as it covers screen controls.
Having it on a separate monitor would work well, but I bet not a lot of people wish to use two monitors for their machine.
Changing the size of the window is the best compromise. I will have to build some concept screens.

5. When an alarm situation happens running a program the program goes back to the start?

That's a hard one to fix reliably I think. I could keep track of the last line that linuxcnc keeps track of, but I don't think it is terrible accurate. I think the highlight line is not always displaying what actually happenning - I will do research..

6. Can there be a wear offset column added to the tool edit page?

Thats another hard one to fix reliably. I could add this to my widget and fake it to linuxcnc, but it would be easy to write a program to break it, which would not be fun! We need linuxcnc to understand the concept of wear offsets. Nobody I know of is working on that.

7. Can there be a diameter comp column added to the tool edit page?

I am not sure I know exactly what you mean - unless you are referring to wear offsets for diameter - same problem as above.

11. Could the scroll bars be bigger for better use with fingers?

This is controlled by the GTK theme, which can be customised. I have not tried that, and really don't have the time. - maybe someone else will build a nice machine control theme

12. Can the button borders be thicker to have more definition between buttons?

Same - controlled by GTK theme

16. The spindle speed background color I cant change from the tan color?

Not sure why - it seems to work fine for me. It may have to do with you using 12.04 (I do not at the moment) I will look at that in time but probably not soon

3. asterisks will be fine

4. changine the size of the graphics is indeed the best compromise

5. it will be ok if it is not dead on. I know that the machine buffers run ahead. It is good for a refference. We have a job that runs 6 hours and spends 3 hours on the same tool. We know what too it is on but have to start at the tool change and it could only have 10 min left. So that tool runs dry for 2 hours and 50 min. untill it is caught back up.

6. I was under the impression that LinuxCNC was not at this point yet either. A fake job might do if it is a good fake. Cubic Zirconia vs Diamond

7. this decribes diameter compensation www.timgoldstein.com/cad_cam/diacomp.htm

11,12. I will look into this I am trying to make a theme for our shop. The theme I posted screen shots of a few days ago works on 10.04 and 12.04.

16. I think I have mis spoken. The tan changes to green like it should when the speed comes up. I want to be able to change the tan.

cmorley wrote:

Yes I have already pushed them, last week I think

Chris,

Thanks for doing this. It now works great on my simulator. I'll try it on the mill later in the week.

A couple more very minor things:
1. When selecting jog increments, continuous is below the smallest increment. My preference would be at the other end of the list -- above the largest increment.
2. If an axis moves such that another digit is needed in the DRO display, it seems the width of the axis select buttons and width of the <Absolute> and <Relative> columns change to balance things horizontally. This works nicely unless the axis is sitting at a transition point. For instance, if it's at 10.0000, servo and encoder uncertainty can make it jump back and forth between 9.9999 and 10.0000. The constant changing in width of the axis select buttons and the <Relative> and <Absolute> columns is a bit annoying. Could these columns be made fixed width yet allow room for the largest expected DRO values?

Thanks.

Karl

karlkec wrote:

2. If an axis moves such that another digit is needed in the DRO display, it seems the width of the axis select buttons and width of the <Absolute> and <Relative> columns change to balance things horizontally. This works nicely unless the axis is sitting at a transition point. For instance, if it's at 10.0000, servo and encoder uncertainty can make it jump back and forth between 9.9999 and 10.0000. The constant changing in width of the axis select buttons and the <Relative> and <Absolute> columns is a bit annoying. Could these columns be made fixed width yet allow room for the largest expected DRO values?

Just a note since this was brought up. We have a machine the has 102" X trravel and 100" Y travel.

andypugh wrote:

cmorley wrote:

Thats another hard one to fix reliably. I could add this to my widget and fake it to linuxcnc, but it would be easy to write a program to break it, which would not be fun! We need linuxcnc to understand the concept of wear offsets. Nobody I know of is working on that.

I said I was going to look at the tool table, and that is part of that.
I haven't even started yet, though.

That would be great Andy.
The wear offsets has been a sore spot for the pros for awhile.
I _really_ don't want to fake something that could potentially crash the machine.

tjamscad wrote:

Chris,

Just for encouragement I downloaded Mach3 and ran it in demo mode. I think it has more features that are part of its base that LinuxCNC doesn't have yet. However the interface and I tried several made it cumbersome to use. Great work with gscreen!

Well you guys can thank yourselves too!
Feed back from everyone drives the changes.

Chris M

karlkec wrote:

cmorley wrote:

Yes I have already pushed them, last week I think

Chris,

Thanks for doing this. It now works great on my simulator. I'll try it on the mill later in the week.

A couple more very minor things:
1. When selecting jog increments, continuous is below the smallest increment. My preference would be at the other end of the list -- above the largest increment.
2. If an axis moves such that another digit is needed in the DRO display, it seems the width of the axis select buttons and width of the <Absolute> and <Relative> columns change to balance things horizontally. This works nicely unless the axis is sitting at a transition point. For instance, if it's at 10.0000, servo and encoder uncertainty can make it jump back and forth between 9.9999 and 10.0000. The constant changing in width of the axis select buttons and the <Relative> and <Absolute> columns is a bit annoying. Could these columns be made fixed width yet allow room for the largest expected DRO values?

Thanks.

Karl

1) I wonder if having Gscreen look for 'continuous' in the INI file, under INCREMENT=. Then you could put it anywhere you want....
2) Yes. That would be annoying. There are a few things like that. I will try to look at that specifically.

Chris M