Gscreen - a GTK / Glade / Python based screen

cmorley wrote:

ok you can add 'continuous' to the DISPLAY INCREMENTS section in any order.
Chris M

Chris,

Thanks for adding this.

As an exercise I tried putting in code to set the initial jog increment. I modified industrial_handler.py and in the __init__ function for HandlerClass I inserted the following:
self.gscreen.set_jog_increments(vector=1)
When run it gave this error:
File "/home/milluser/linuxcnc-dev/bin/gscreen", line 1886, in set_jog_increments
self.halcomp["jog-increment.out"] = distance
AttributeError: Pin 'jog-increment.out' does not exist

I assume jog-increment has not been set up at the point HandlerClass is being initialized. Is there a different place I could make a call to set_jog_increments, after everything is initialized, to set the initial jog increment?

Thanks.
Karl

That would need to go in the init_widgets section.

In Gscreen proper the order is:
parse handler file and call it's __init__
make basic Hal component
initialize_pins
connect_signals
initialize_widgets

any one or all of the last three can be in the handler_file and the order is the same.
try adding it to the initialize_widgets section
you'll see a couple of others there as well as a lot of calls to gscreen's individual initializing functions.

Chris M

cmorley wrote:

I think this is a problem with the system links.
I only have worked with Gcsreen as a Run-in-place build.

by using buildbot it's an installed build which moves a few things around.

There are system-links (shortcuts) that are pointing to the wrong place.

Where ever sim/axis/core_sim.hal is pointing to
sim/gscreen/core_sim.hal must point to

There are probably a couple others too. hal_manual_toolchange.hal etc

Chris M

Or maybe the system links are missing when copied into your linuxcnc folder...

I had to copy files from the axis sim directory and create empty files, named xxxx_postgui.hal, and it is working.

Chris,

gscreen-industrial has some new issues since the last push

cmorley wrote:

That would need to go in the init_widgets section.

In Gscreen proper the order is:
parse handler file and call it's __init__
make basic Hal component
initialize_pins
connect_signals
initialize_widgets
Chris M

Chris,
This works well. Thanks.
One more thing for your list -- the new asterisks next to each DRO axis don't go away when the axes are unhomed.
Karl

ok fixed some things.....

Chris M

cmorley wrote:

ok fixed some things.....

Chris M

\
Hi Chris,

I see the homing asterisks seem to now work well. Thanks.

I was thinking about the DRO numbers. On the 3-axis mill we have a 19" screen on a swing arm. It's often several feet from the operator, and the DRO numbers are kind-of small at this distance. It's too bad since there's so much extra room in the DRO area on a 3-axis machine.

I know it's this way to accommodate 9 axes, and I agree with the reasoning. On a 3-axis machine if the rel, abs, dtg values were arranged vertically instead of horizontally (I know, I know, going backwards), I think they could be made quite a bit larger.

Thinking of other users, is there a way to separate the DRO area into its own layout file (glade?), and have different files optimized for different numbers of axes. It's a rare day that the number of axes on a machine changes, so I don't think it matters much if it requires some setup effort. I don't want to make more work for Chris, but if this is feasible I might try to tackle it myself.

Any thoughts?

Karl C

I assume you mean the 'industrial' screen, the default Gscreen has a slightly larger DRO.

There is no need to have a separate second GLADE file for different DRO layouts - you edit the existing GLADE file to what you want.

In fact this is what Industrial is - a customized Gscreen GLADE file.
Now some things you change you must change the python code that controls it. Industrials 'tab' buttons are an example.
Other things -such as the DRO are quite flexible without Python code.

For instance to make the DRO larger you can change the attributes of each of the HAL_DRO widgets.
attributes control color size/scale, weight, style etc
As long as you keep the same names of the HAL_DRO widgets you can move them around.
If you have a machine that never will use the UVW DRO widgets, you can erase them.

Using Glade takes some time to get used too - It's not exactly what-you-see-is-what-you-get.
If you are using RIP build you must be in that environment and launch GLADE from the terminal so it is aware of all the HAL widgets.
If you have an installed build, it should work normally.

If you edit the sample glade file, when linuxcnc updates it will overwrite the changes.
So making a separate config would be wise.
The other side of this is if I upgrade Gscreen glade file and you wish to use it you will have to edit it again.
This will be annoying while heavy developing is happening, but after release it should be no big deal.

Chris M

It's in fact this user customization option that drove Gscreen's development. By leveraging gladeVCP's handler file code now you can build truely custom screens. Soon Norbert's Gmoccapy will be available in master - it is _really_ different from Gscreen.

Hallo Chris,

I got now all the confirmations about the use of the ICONS.
I will add a list to the code so everybody knows exactly where the Icons are from.

I didn't send you the code jet, because I need to clean it up a little and add more comments and will then
make some more videos to explain the configuration. I added also user Tabs, side panels
and have to make some useful panels to show how this works.

Please give me be a little bit more time.
Hope to be ready during next week.

Norbert

Hallo Chris,

I got the following problem.

I open gscreen, then I went to preferences.
I toggle "Hide Cursor" and the cursor is gone.
Now I go to normal mode and switch on the machine, then go back to preferences and close
gscreen by clicking the exit button.

Now try to open gscreen from the terminal again.
In my case the X-Server crashes!

Can you reproduce the behavior?

Norbert