Gscreen - a GTK / Glade / Python based screen

Hallo Chris,

can you make the Key Bindings dynamically?
I meen a INI File like so:and so on, so it is editable from the user, allowing more individualism.

Regards Norbert

Not sure if this is workable.
The reason is keybindings call methods.
Your methods (Gmoccapy) could be different from my methods.
It could cause errors or un wanted movement

Well I guess I could add a method to parse the INI and add them to a lookup table then it would be up to the screen to us that to call methods.

I pushed a experimental key binding sample.

escape = estop
i = increments up
shift i = incremennts down

up down -jog axis 0
left right - jog axis 1
page up page down - jog axis 2

One problem that came up is key repeating.
When using incremental jogging if I don't trap the key repeat then the increments repeat.
I trapped axis 0 but not the axis 1 or 2.
carefully try each way and see what you think.
This may or may not work with Gmoccapy

Chris M

Halo Chris,

I just took a short look on the code. Wouldn't it be better to include:

initialize_keybindings(self):
in
def initialize_preferences(self):

instead of having it "stand alone" ?

So we are more flexible and a user is able to overide with it's own handler file.
As far as I can see from now, it will be necessary for nearly every future custom GUI based on gscreen, because the widgets will mostly have there own names.

I do hope, I don't insult you, if I say I am very unhappy with the internal names of the gscreen widgets, because they mostly don't represent the funktion to execute. button_0_1 is not so easy to understand as btn_enable_jog. This is the reason I renamed 99% of the widgets.

I hope to get a little time this evening to test, but I first have to actualize the DOKU of gmoccapy.

Norbert

cmorley wrote:

Tjamscad

No I haven't pushed it yet.
Is having the keyboard on that side ok? or should the regular vertical gscreen buttons be on the right of the keyboard?

Chris M

Yes that side is ok. It is a great idea to make it selectable in the prefferences ar Rick has asked for. Maybe even better than that would be a prefferences for position as well as shown or not shown.

How would you go about unlinking the cycle start button on the screen and making it an output signal? I'm sure something in the handler file, which for me currently is like trying to get an infant to fly the space shuttle.

With a little direction on this I would like to dabble with this one. I think its not specific to our requirements but I need to learn this stuff sooner than later so why not start now.

Reason I ask is we have our other machine setup with some inhibit signals. I have a python screen as part of my AXIS interface, with cycle start, feed hold, and cycle stop buttons, all just having a hal output bit going to my ladder so I can control start permissions. We did it this way so if something is not proper you cannot start an NC program, and if you are already in the middle of running a program, it will let the program finish and not be able to be restarted. This way your not making unnecessary E-Stops, and ruining parts for no reason.

Thanks

Rick

newbynobi wrote:

Halo Chris,

I just took a short look on the code. Wouldn't it be better to include:

initialize_keybindings(self):
in
def initialize_preferences(self):

instead of having it "stand alone" ?

So we are more flexible and a user is able to overide with it's own handler file.
As far as I can see from now, it will be necessary for nearly every future custom GUI based on gscreen, because the widgets will mostly have there own names.

Yes that's why I said it was experimental I was in a hurray. I need to think about how to handle an INI selection process, but wanted to be sure the keybindings actually work.

I do hope, I don't insult you, if I say I am very unhappy with the internal names of the gscreen widgets, because they mostly don't represent the funktion to execute. button_0_1 is not so easy to understand as btn_enable_jog. This is the reason I renamed 99% of the widgets.

Norbert

I'm not insulted.
Yes button_v0_1 was the original idea of defining buttons by position rather then function.
afterwards it became apparent by function was better.
slowly I am changing.
Gscreen is still in development just as Gmoccapy And I really didn't have a detailed plan.

Chris M

tjamscad wrote:

cmorley wrote:

Tjamscad

No I haven't pushed it yet.
Is having the keyboard on that side ok? or should the regular vertical gscreen buttons be on the right of the keyboard?

Chris M

Yes that side is ok. It is a great idea to make it selectable in the prefferences ar Rick has asked for. Maybe even better than that would be a prefferences for position as well as shown or not shown.

Well what I think is reasonable to support is a good default position and a way to disable Onboard.
To move it's position is always possible using a modified GLADE file.

Chris M

LAIR82 wrote:

How would you go about unlinking the cycle start button on the screen and making it an output signal? I'm sure something in the handler file, which for me currently is like trying to get an infant to fly the space shuttle.

With a little direction on this I would like to dabble with this one. I think its not specific to our requirements but I need to learn this stuff sooner than later so why not start now.

Reason I ask is we have our other machine setup with some inhibit signals. I have a python screen as part of my AXIS interface, with cycle start, feed hold, and cycle stop buttons, all just having a hal output bit going to my ladder so I can control start permissions. We did it this way so if something is not proper you cannot start an NC program, and if you are already in the middle of running a program, it will let the program finish and not be able to be restarted. This way your not making unnecessary E-Stops, and ruining parts for no reason.

Thanks

Rick

This is not too hard - I think

It requires you to modify the GLADE file.
One consequence of that is anytime Gscreen is updated, you need to update the glade file again (assuming it changed in the update)

If I add a couple HAL pins to Gscreen then you won't need a handler file.

I assume you want the Start button to stay on screen and work but go through your ladder program.
You need to change the start button from the existing toggle button to a HAL regular button.
This means it will have a HAL pin that toggles as it's pressed.
connect this to your ladder.

Then you need a HAL pin to send the start command.
While you can do this in the handler file, what I can do is add the pins to Gscreen so you only have to connect to them.
Hopefully that's all it will take...

I'm sure you will need more detail...

Chris M

Oh wait :

gscreen.cycle-start is already available in Gscreen..

When I get in monday I will send you how it works for me, but I do know I have to set the halui auto mode then it fires the halui program run input pin if my permissions are good. I guess if there was just a cycle start inhibit hal input pin I could link to it would do the same thing.

I will hit it on monday.

Thanks Chris

Have a good weekend.