Gscreen - a GTK / Glade / Python based screen

cmorley wrote:

If you hide the pointer in the preference page then you don't need to double click, a single click will do.
I am probably going to get rid on the spinbutton, though probably a button to bring up the calculator would be handy.

I'd forgotten about hiding the pointer. Thanks for the reminder.

For a right handed person buttons on the right should be fine. I never really liked the buttons on top, though the layout worked a little better.

I think buttons on the right would suit me just fine. And I'm fine with rearranging things myself according to my preferences.

Karl

Norbert

What checkbox are you missing - I don't follow you.
The password is for industrial only. Gscreen doesn't know about it at all. so it is appropriate to be in the handler file ( I think anyways)
To be able to edit it in the preference file defeats the purpose of it.
Gremlin not plotting path correctly - I can't do much with that - file a bug report to the maillist please.
Gremlin not reloading after a new origin set, I can fix. how did you set the new origin?
An integrated keyboard is possible, but requires some more work and dependency that the linuxcnc project may not want ( at least to do it properly)
use TOOL_EDITOR = gedit and test in default gscreen with the button 'tool editor' but why do you wish to use gedit over the tooleditor widget?

Hay Chris,

i would like a checkbox for the decision to reload the tool after restarting linuxcnc. At the moment closing Gscreen will unload the tool. After a restart the tool will be "0" and you will have to set the tool in spindle with "M61Qn". It would be fine, just to save the tool number on closing gscreen and reload the tool after restarting gscreen. But as discused here in the forum not every user want this, so why not decide on the checkbox state if the tool will be reloaded or not.

About the password: I just thought that a clear password in a hidden file will be a little bit more secure than in the code. Not in the meaning of getting the password, just because not everybody is able to treat the handler file with the affordable respect. And if you touch the password case, just hide the entered password in the calculator entry.

The not correct shown path is not only a gremlin problem, it is also a gscreen problem. On my screen it is working nearly perfect, on yours not. To check out, please do the following.

Load a program to run, then change to manual mode and jog to a different position, lets say go relative Z-20 X-10 Y +30 mm
On this position cero the workpiece coordinate system. In relative all DRO should now show "0.000"
Go back to auto mode and just click "cycle start" and see what is going on. In my opinion there is no reload step after setting the coordinates of the workpiece to a new position. I am doing this on gmoccapy and it is working fine.

If you are not able to follow me, I am able to mail a video.

Integrated Keyboard, not a complete one, just to change smaller thinks on the machine. I just included one in gmoccapy, may be it is useful for your decision.

Last not least: the tool editor: What if a user want's to use gedit, because he pimped it up to handle gcode? He will not be able to use it, because you are forcing him to use your one. You give the user the right to choose the tool-editor, but not on the editor. This is just a comment, I can live fine with the editor.

Hope I cleared all items.

Norbert

Tool reload checkbox option is an interesting idea!

At the moment only industrial has a password option - I think I will add the code to Gscreen and as you said add it to the preference file.
Whether I have default Gscreen use the password - I'm not sure. I was also thinking it may be nice to have two passwords on to get you the preference page another to get you evrything (alarms,debug,preferences)

As for the not-reloading-after-origin-shift problem - i fixed that a while ago. I tested just now and it seems to work fine.
Are you sure your version is based on an up to date master?

I am not too interested in building a keyboard, other then the numerical one that I did. I would rather work on integrating the Onboard program.
It is possible to embed it into Gscreen - and you can make custom keyboard layouts.
Getting a keyboard to work reliably in all situations is quite a mission - as you can see if you look at Onboard's source code.
I prefer to enjoy their hard work rather then try and learn all their mistakes the hard way

As for the editor:
I didn't realize that you could set an editor for tool offsets and an editor for Gcode.
Gscreen already allows using a different editor for tool offsets, I will add the Gcode editor option.

I might point out though there is not much that is truly restricted in Gscreen, I make common wants default or easy to choose, but one can always
change the behaviour of Gscreen. While you still have to program python to do it, it is considerably easier then say AXIS.
Or at least I hope it is !

I am currently working on having the offsets page allow editing of the offsets. It seems to work fine now. Need to clean it up.
To begin you will only be able to edit the current G5x offsets, but there is no reason I can see why it couldn't be expanded to all the user systems.

Chris M

Chris,

I did a bit more work with gscreen on the mill. gscreen is really working well and I'm getting more used to it.

In Jogging Mode, continuous jogging (joysticks) doesn't work after Indexing a Tool. Same for the jogwheel. If I re-start Jogging Mode, it works again.
Also, a really minor thing in the tool editor: there is no column separator between the diameter and comment columns.

I ran a couple of simple programs and some MDI commands and it all seems fine.

Looking good.

Karl

Yes I see the separator missing in the tool editor. I don't know why it does that as it shows it fine when I test without gscreen. Bug?

The jogging mode problem, is really a mode switching problem.

This like origin shift, origin zero, tool index, coordinate shift are actual done with MDI commands.
it's reliably switching back to manual mode (jogging requires this) that is the problem.

I'm fairly stumped right now. Tool index is different from say origin shift.
Tool index needs to wait till a HAL pin changes and this waiting screws me up.

The fact that these things need to be done in MDI is wrong IMHO but that the moment that is the only way to do it.

Chris M

@Chris

This like origin shift, origin zero, tool index, coordinate shift are actual done with MDI commands.
it's reliably switching back to manual mode (jogging requires this) that is the problem.

..........

The fact that these things need to be done in MDI is wrong IMHO but that the moment that is the only way to do it.

I think this is done, because all these commands need all axis to be homed. That is the only possibility to be sure softlimits will be taken care off.

I got the index tool button on the manual page and do sensitize this button only if all_homed is true.
Before indexing I switch to MDI mode and after doing this I switch back to MANUAL mode.

May be that is also a solution for you.

Norbert

Norbert

@Chris,

I don't know, if the following is your matter:

Please take a loog at hal_souceview, wenn running code, the actual line will be highlighted.

First the forground / background color combinations are not very beautifull, because the contrast is very low.

And second: If the program i.e. ends with M2 at line 96, the last highlighted line will be around 87. I think we should consider this behavior as a bug.

Norbert

newbynobi wrote:

@Chris

This like origin shift, origin zero, tool index, coordinate shift are actual done with MDI commands.
it's reliably switching back to manual mode (jogging requires this) that is the problem.

..........

The fact that these things need to be done in MDI is wrong IMHO but that the moment that is the only way to do it.

I think this is done, because all these commands need all axis to be homed. That is the only possibility to be sure softlimits will be taken care off.

I got the index tool button on the manual page and do sensitize this button only if all_homed is true.
Before indexing I switch to MDI mode and after doing this I switch back to MANUAL mode.

May be that is also a solution for you.

Norbert

Norbert

I agree that homing must be done. I don't agree that it needs to be in MDI.
I can not switch back to manual after a tool change automatically.
Are you sure you have switched back? If you open the status program you can see what mode your in.
If you switch to manual mode too soon then the tool change doesn't happen.
I will have to look at your code carefully.

Chris M

Halo Chris,

Attention:
You are speeking about an complete tool change!
I just do an M61Q23!, not an tool change!

For me indexing a tool is not changing it.

A real tool change I am doing only in MDI ore AUTO mode at the moment.

Norbert

Chris,

I just noted that clicking on the header of Tool# and Pocket# in tooledit widget will change the order, sort them.

Would it be possible to make this also for the diameter column?

I have at the moment only 23 tools in my tool file, but on my working machine I have about 50 tools, so searching for a certain tool diameter, i.e. a 3,2 mm drill would be easier.

Norbert