Gscreen - a GTK / Glade / Python based screen

Hi Chris, so far so good with our build, we are going to start cutting chips tomorrow, can't wait!!! I will let you know how things go after some cycle time.

One thing I noticed late yesterday, I was noticing that when I was typing in an mdi command, the letters/numbers were lagging behind a little half a second maybe before they appeared in the actual box. I noticed that the 2nd small screen with the speed meter was behind the main screen, so I turned it off in preferences and the lag disappeared. Peculiar........

I have been pondering for a while, how to get a user defined fault displayed somewhere on our builds. Now with gscreen, you have them displaying in the top left hand field. How is that handled, and how do you think you could take an external hal input and have it trigger an alarm in that display?? Its something I would like to try to tackle if its even feasible. I started a thread "External Fault" in advanced configuration last year, but I wasn't anywhere near where I am at with programming as I am now. Now I now just enough to be dangerous!!! Ha ha ha

Thanks

Rick

newbynobi wrote:

Hallo Chris,

feel free to get code of mine.

Norbert

What I am doing is embedding Onboard (launchpad.net/onboard) into Gscreen.
opposed to launching Onboard separately.
I'm not interested in building a keyboard program as Norbert has done.
In this way a user could build what ever type of keyboard he likes and I don't have to maintain code.

I will play with the layout a bit.

Chris M

LAIR82 wrote:

Hi Chris, so far so good with our build, we are going to start cutting chips tomorrow, can't wait!!! I will let you know how things go after some cycle time.

One thing I noticed late yesterday, I was noticing that when I was typing in an mdi command, the letters/numbers were lagging behind a little half a second maybe before they appeared in the actual box. I noticed that the 2nd small screen with the speed meter was behind the main screen, so I turned it off in preferences and the lag disappeared. Peculiar........

I have been pondering for a while, how to get a user defined fault displayed somewhere on our builds. Now with gscreen, you have them displaying in the top left hand field. How is that handled, and how do you think you could take an external hal input and have it trigger an alarm in that display?? Its something I would like to try to tackle if its even feasible. I started a thread "External Fault" in advanced configuration last year, but I wasn't anywhere near where I am at with programming as I am now. Now I now just enough to be dangerous!!! Ha ha ha

Thanks

Rick

Gscreen is a userspace program so is at the mercy of the realtime kerel.
Gscreen is of course a python program so is a little slow and it's many layers deep.
There are a few settings that can help.
There is the update rate of gscreen. too fast uses up CPU time, too slow makes Gscreen unresponsive.
This is set in the INI under [DISPLAY] CYCLE_TIME = 100

There is the base/servo period of linuxcnc - a larger number leaves more time for user space programs.

The display card/driver may have an effect too.

Gscreen has a built in mechanism for HAL pin controlled messages.
There are status bar messages, ok dialog or yes no dialog messages.
The status bar messages can be combined with the dialog messages and they also pop a message notification bubble.
These samples are included in the default Gscreen config in the sim folder.
in the debug terminal try these commands:
halcmd setp gscreen.statustest 1
halcmd setp gscreen.yndialogtest 1
halcmd setp gscreen.bothtest 1

You can set the type and message test in the INI file.
You can add HAL logic to control stuff depending on the answer of say the yes no dialog.
You could also you a hadler file and extend Gscreen to do what ever you want message / dialog wise.
look here:
wiki.linuxcnc.org/cgi-bin/wiki.pl?Gscreen#user_message_dialogs

Hope that helps.

Chris M

adding an image makes the keyboard more square ... Stuart might like this

Chris M

I was fooling with keyboard bindings.
Is this something we should have for Gscreen?

What would we want a keyboard binding for - everything?
I would need to make it extendible in a handler file which is fine.

Maybe I should try to follow AXIS's bindings if I can.

Or maybe Gscreen is fine with touchscreen and mouse....

Chris M

Hallo Chris,

please do the keyboard bindings! And make it available for custom screens, so I don't have to do the work for gmoccapy myself
I really think we should follow the axis bindings.

Would you make a MPG Wheel for glade? Like the one existing for pyVCP ?
We mentioned this in a previous email, but forgot about it.

I was thinking about writing an glade file representing a hand wheel to control simulated machines.


Norbert

Hello Chris,

I am definitely going to look into the user messages, now that you pointed me in the right direction. Thank you,

I am fully a proponent for using AXIS style bindings, I've actually been trying to figure out how to accomplish just a few keys for the guys. They have come to like the up/down left/right buttons for jogging. Our up/down button is backwards in our case because of our tools being on the top/back of the part. I could modify that though if can get the basic bindings going. I was able to modify the axis.rc file on our other one to jog correctly.

Again, nice GUI

Thanks

Rick

cmorley wrote:

adding an image makes the keyboard more square ... Stuart might like this

Chris M

Very nice, has this been pushed?

that lower right hand corner does look VERY good