Gscreen - a GTK / Glade / Python based screen

cmorley wrote:

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.

Hi Chris,

Is it a problem of knowing when to tell it to switch back to manual mode? Have you tried polling halui.program.is-idle? Or maybe you aren't using halui. Have you looked to see how touchy does this?

I'm full of questions but no answers.

Karl

cmorley wrote:

Sample of bottom buttons for industrial:

I like it, I like it

Chris,
I asume this is still concept at this point?

I have not pushed this yet, I am removing the entry box. which involves a fair bit of code.
I hope it's not a mistake....
maybe I should push with the entry box still there first??

As pyngcgui is embedable, there is no reason it shouldn't work. The reason I haven't tried it is pyngcgui is in V2.5 and Gscreen in master. so it's a bit of work to try it. I have been busy with other things.

Chris M

karlkec wrote:

Hi Chris,

Is it a problem of knowing when to tell it to switch back to manual mode? Have you tried polling halui.program.is-idle? Or maybe you aren't using halui. Have you looked to see how touchy does this?

I'm full of questions but no answers.

Karl

I don't use halui but I use the same mechanism as halui uses.

The problem comes from waiting for tool change to finish blocks Gscreen from doing anything else.
Since manual tool change dialog needs Gscreen to function so it can pop up the dialog, you can see the catch 22

I could add the switch back to manual to the dialog finishing but then i have to add a bunch of logic to decide if the tool change started from manual,
or was from MDI or AUTO. Not very nice and easy to break.

Asking questions often leads to answers!

Chris M

cmorley wrote:

The problem comes from waiting for tool change to finish blocks Gscreen from doing anything else.
Since manual tool change dialog needs Gscreen to function so it can pop up the dialog, you can see the catch 22

I could add the switch back to manual to the dialog finishing but then i have to add a bunch of logic to decide if the tool change started from manual,
or was from MDI or AUTO. Not very nice and easy to break.

Chris M

How about a custom realtime component to monitor the tool change and tell gscreen when it's complete via a HAL pin.

I know it's kludgey, but would it work?

Karl

This could work, it's really an extension of using the dialog finishing to signal being done.
And it has the same problem, I have to know what mode we were in before tool change was called.

It's really a fundamental problem with doing toolchanges in MDI.
Or it would be nice to have linuxcnc switch back to the mode it started in.

I'd rather have toolchanges in Manual mode.

BigJohnT wrote:

cmorley wrote:

I have not pushed this yet, I am removing the entry box. which involves a fair bit of code.
I hope it's not a mistake....
maybe I should push with the entry box still there first??

As pyngcgui is embedable, there is no reason it shouldn't work. The reason I haven't tried it is pyngcgui is in V2.5 and Gscreen in master. so it's a bit of work to try it. I have been busy with other things.

Chris M

No biggie, Just thought I'd ask. I'm good for now using Touchy-Gremlin-Pyngcgui.

John

I added Deweys patch to master to try integrating it in to Gscreen.
It seems Dewey doesn't use the 'standard' embedding technique, he patches TOUCHY to load pyngcgui
I don't really like this - so I sent an email to Dewey to discuss.

Chris M

Hay Chris,

I do monitor the mode in gmoccapy code.

Please take a look at

def _set_spindle(self, widget, data=None):

around line 381, may be this could be helpfull.

Norbert