Gscreen - a GTK / Glade / Python based screen
01 Jan 2013 07:52 #28244
by cmorley
13) every time you add tabs it uses vertical space. They are great when there are lots of tab options. If I had the mode as tabs then that would have mode tabs inside of menu tabs which wastes a great deal of space. I would assume in general one would not change modes much after the machine was set up and running.
16) not practically - ignore-limits unsets it's self right after a jog command (linuxcnc does this) so it is much handier to have the button available while jogging off the limit switch.
Chris M
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
8. please rename to option stop or optional stop
9. Please use text
10. Thanks I can handle that
12. see #10
13. The tabs are very nice and very fast to change between screens. Tabs could better be used in the Modes were tabs also. The multiple toggle button works but I find myself passing the mode i want and having to go areound and back to it.
14. Yes, estop on = red, estop off = black
15. yes, the sample sim/gscreen_custom but with the color changes from point 14. Machine on = green machine off = black
16. Is that something that can be toggeld in debug of prefferences?
17. This can be adressed at a later date if nesseary I was just thinking that it could help with room for othere items.
On screen keyboard - is it possible for it to show the text that will be avaible when using the shift key?
13) every time you add tabs it uses vertical space. They are great when there are lots of tab options. If I had the mode as tabs then that would have mode tabs inside of menu tabs which wastes a great deal of space. I would assume in general one would not change modes much after the machine was set up and running.
16) not practically - ignore-limits unsets it's self right after a jog command (linuxcnc does this) so it is much handier to have the button available while jogging off the limit switch.
Chris M
Please Log in or Create an account to join the conversation.
- JaysonWallis
- Offline
- New Member
Less
More
- Posts: 15
- Thank you received: 0
01 Jan 2013 14:23 #28247
by JaysonWallis
Replied by JaysonWallis on topic Gscreen - a GTK / Glade / Python based screen
I have been using Gscreen all week and its working well.
One small thing that I have noted is that if there is an error in the .nc file Gscreen throws up a bunch of python errors.
If I load the same file into axis it gives me the line number and points to what the error is.
Just makes it a little easier to find where I stuffed up
Thanks,
Jayson.
One small thing that I have noted is that if there is an error in the .nc file Gscreen throws up a bunch of python errors.
If I load the same file into axis it gives me the line number and points to what the error is.
Just makes it a little easier to find where I stuffed up
Thanks,
Jayson.
Please Log in or Create an account to join the conversation.
01 Jan 2013 16:36 - 01 Jan 2013 17:59 #28248
by cmorley
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
Ironically the error is from the code that is suppose to report the Gcode error.
This is a problem in the HAL_gremlin widget. Was hoping Pavel would fix it (he made HAL_gremlin)
I might look into it though...
Glad you find Gscreen useful!
Chris M
This is a problem in the HAL_gremlin widget. Was hoping Pavel would fix it (he made HAL_gremlin)
I might look into it though...
Glad you find Gscreen useful!
Chris M
Last edit: 01 Jan 2013 17:59 by cmorley.
Please Log in or Create an account to join the conversation.
01 Jan 2013 18:01 #28249
by cmorley
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
ok added override enable HAL pins.
also added 'industrial' as a sample config
it has most of the ideas you guts talked of besides the ones that take alot of work...
Chris M
also added 'industrial' as a sample config
it has most of the ideas you guts talked of besides the ones that take alot of work...
Chris M
Please Log in or Create an account to join the conversation.
01 Jan 2013 20:54 #28251
by BigJohnT
Replied by BigJohnT on topic Gscreen - a GTK / Glade / Python based screen
Chris, you might take a look at the Gremlin example I finally got working with the help of Rogge that doesn't use the gladevcp widget to implement gremlin. It seems like a better solution to me at this point as you can handle the file load error as you like without a python error showing up.
John
John
Please Log in or Create an account to join the conversation.
02 Jan 2013 00:30 #28264
by karlkec
1. I'll try it.
2. The track ball movement works just like a mouse. The advantage is it doesn't need a flat surface to work on.
4. I didn't think of the problem of doing tool changes prior to homing. That obviously can't work.
We often index tools out of order. This is not a production shop, and we leave some "standard" tools in the changer. A particular job might use some of those tools plus ones added in higher tool numbers just for that job.
What I was thinking about for a setup tab is to edit the tool table, set origins, and touch off tools. The setup process for us is like this: home the machine, load an edge finder tool, set X and Y origins, load a reference tool, set Z origin, then load and touch off each tool for the job, It is reassuring to see the Z offset in the tool table change after touching off a tool.
5. ok. I'll think about this.
6. I got it. Thanks.
Thanks a lot, Chris.
Karl
Replied by karlkec on topic Gscreen - a GTK / Glade / Python based screen
Hi Chris,1) you can almost do this now by using halui override controls. The missing part is the on-screen enable controls.
I could create pins that are true only when one of the override buttons is selected and while not in jogging mode - is that sufficient?
2) it is possible to zoom in anyway you want with a little coding. Is the track ball used like a mouse? so track ball movement is the same as mouse movement?
3) Yes ideally the tool editor display will be more configurable. I hadn't decided how that should work at the time I built it.
4) tool changing requires the machine to be homed that is why I left it off the first screen. I know on my lathe we indexed tools manual fairly often.
I could add it, de-sensitized till homing is done. Could you llive with index next tool or would you need index to a particular tool?
As for tooleditor as a setup tab- I'm not sure what you mean exactly - are you saying you want to be able to set the origin while the tooleditor displays?
5) If tabs are easier to use yes an offset tab could be built.
6) Jogging is available without homing. Homing mode is set automatically when Gscreen is started as that is pretty standard. de-press the homing button on the right side and press the jogging button on the bottom left. If this is an option lots of people want I could add it as a preference.
1. I'll try it.
2. The track ball movement works just like a mouse. The advantage is it doesn't need a flat surface to work on.
4. I didn't think of the problem of doing tool changes prior to homing. That obviously can't work.
We often index tools out of order. This is not a production shop, and we leave some "standard" tools in the changer. A particular job might use some of those tools plus ones added in higher tool numbers just for that job.
What I was thinking about for a setup tab is to edit the tool table, set origins, and touch off tools. The setup process for us is like this: home the machine, load an edge finder tool, set X and Y origins, load a reference tool, set Z origin, then load and touch off each tool for the job, It is reassuring to see the Z offset in the tool table change after touching off a tool.
5. ok. I'll think about this.
6. I got it. Thanks.
Thanks a lot, Chris.
Karl
Please Log in or Create an account to join the conversation.
02 Jan 2013 00:32 #28265
by cmorley
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
Well while that would fix the error code being thrown that would create a lot of work for me and then restrict users from customising Gscreen's graphics plot, which is one of Gscreen's objectives.
Also fixing the HAL_gremlin error seems a better thing for a developer to do then just stop using the widget.
I can suppress the error messages easily by overriding the method that prints them to standard error and changing it to a print statement.
This shows me that the error message is being written twice, which seems to indicate the loading of the program is being done twice.
Not sure why that causes an error rather then just printing twice though...
I'm sure someone who knew how to use a debugger could figure out why it's being called twice - I just don't know how to use a debugger.
I did a few print statement debugging and haven't found it yet - I wouldn't be surprised if it's a glade signal being called twice.
Chris M
Also fixing the HAL_gremlin error seems a better thing for a developer to do then just stop using the widget.
I can suppress the error messages easily by overriding the method that prints them to standard error and changing it to a print statement.
This shows me that the error message is being written twice, which seems to indicate the loading of the program is being done twice.
Not sure why that causes an error rather then just printing twice though...
I'm sure someone who knew how to use a debugger could figure out why it's being called twice - I just don't know how to use a debugger.
I did a few print statement debugging and haven't found it yet - I wouldn't be surprised if it's a glade signal being called twice.
Chris M
Please Log in or Create an account to join the conversation.
02 Jan 2013 00:50 #28266
by cmorley
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
Karl
trackball movement and having the offset and origin offset button in the tool table page are good candidates for custom screens.
These are things that I don't think I want to do to the default screen.
I will see about building a sample of those customizations if you like.
Are you using the default screen now or a custom one?
Are you using a touch screen as well as a track ball?
The tool change and offsets page sound like good default features so will look into them.
Chris M
trackball movement and having the offset and origin offset button in the tool table page are good candidates for custom screens.
These are things that I don't think I want to do to the default screen.
I will see about building a sample of those customizations if you like.
Are you using the default screen now or a custom one?
Are you using a touch screen as well as a track ball?
The tool change and offsets page sound like good default features so will look into them.
Chris M
Please Log in or Create an account to join the conversation.
02 Jan 2013 02:04 #28274
by karlkec
Replied by karlkec on topic Gscreen - a GTK / Glade / Python based screen
Chris,
I'm using the default screen. I'll have a stab at doing a custom screen. I want to learn about that anyway.
We're using both the touch screen and track ball. The track ball isn't used much, mostly just the touch screen.
I couldn't get the override enables to work on my simulator. I enabled the machine, homed it, pressed Set Override, and pressed Feed Override. gscreen.f-override-enable-out is still False. Is there something else I need to do?
Karl
I'm using the default screen. I'll have a stab at doing a custom screen. I want to learn about that anyway.
We're using both the touch screen and track ball. The track ball isn't used much, mostly just the touch screen.
I couldn't get the override enables to work on my simulator. I enabled the machine, homed it, pressed Set Override, and pressed Feed Override. gscreen.f-override-enable-out is still False. Is there something else I need to do?
Karl
Please Log in or Create an account to join the conversation.
02 Jan 2013 02:32 #28277
by cmorley
Replied by cmorley on topic Gscreen - a GTK / Glade / Python based screen
As long as your not in jog mode it should work. i just checked it again...
Please Log in or Create an account to join the conversation.
Time to create page: 0.150 seconds