GMoccaPy doesn't fit in 1024x768 resolution

More
22 May 2017 18:37 - 22 May 2017 18:37 #93496 by newbynobi
newbynobi replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
It is not possible to reduce the size lower than 750 pixel, as that would include to rezize all widgets. A lot of coding.
If you use full screen all should fit.

If you have a problem with tool change confirmation, you are using hal-manual toolchange, instead of the gmoccapy one.

just comment out everything with hal_manual_toolchange and add the following lines to your postgui hal file
net tool-change gmoccapy.toolchange-change <= iocontrol.0.tool-change
net tool-changed gmoccapy.toolchange-changed <= iocontrol.0.tool-changed
net tool-prep-number gmoccapy.toolchange-number <= iocontrol.0.tool-prep-number
net tool-prep-loop iocontrol.0.tool-prepare <= iocontrol.0.tool-prepared
See also linuxcnc.org/docs/html/gui/gmoccapy.html#_tool_related_pin

Norbert

Norbert
Last Edit: 22 May 2017 18:37 by newbynobi.
The following user(s) said Thank You: hwylie
More
22 May 2017 19:49 #93501 by hwylie
hwylie replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
Just to add that (after reading more than one week ago) I had erroneously applied the documentation to which you referred, and tried to invoke Gmoccapy manual tool change by way of 'loadusr' - with less understanding of LCNC than at present, overlooking the statement 'gmoccapy's internal tool change dialog'.

Having identified the code in github 'gmoccapy.py' source, the ensuing study is sure to develop my Python understanding!

Confident that a good solution is close at hand, your prompt response (as below) is appreciated.
More
23 May 2017 13:02 #93534 by hwylie
hwylie replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
Following online documentation, downloading the required macro and python files from Master, and adapting .ini and .hal files as required, the Gmoccapy manual tool change prompt appears as expected.

However, the crucial requirement to perform manual jogging and touch-off after tool change is not met, since Gmoccapy manual/mdi control is inhibited while the tool change prompt is in focus (see attached image), irrespective of choice of full-screen, maximised or floating window.

Is it in fact possible to perform manual / mdi functions via the Gmoccapy GUI while awaiting confirmation of tool change? Is something overlooked or incorrect in attached .ini &, .hal files?
Attachments:
More
23 May 2017 17:14 #93553 by newbynobi
newbynobi replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
It is not possible to jog or do MDI commands, during a tool change!
If you want to do that, you need to look at the "moveoff" hal component.

I do not know why you want to do such think.

I have the remap procedur move my machine up, then to a tool change position and after changing the tool it moves back to the previous XY coordinates.

Norbert
More
23 May 2017 18:56 #93562 by hwylie
hwylie replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
We find that a 50mm Z-setter clock gauge placed anywhere on the 2,75x1,83m supawood machine table (on steel base structure) is the most convenient means of setting Z as tools are changed on our gantry router, which has used Axis GUI for a number of years.

'Moveoff' and 'external offsets' branch of LCNC will be examined for alternatives to use with Gmoccapy.
More
24 May 2017 08:34 #93582 by hwylie
hwylie replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
With this context in mind, it may be asked: why not the usual gauge block set/tool table combination for quick tool change?
Stacking the appropriate (possibly several) blocks is prone to error, and the boxed set may be out of arm's reach on the large machine table. The 50mm z-setter clock gauge is light in weight, and less prone to error.

In this scenario, the adopted method is a good approach - preferably with jog pendant when tool change position is some distance from LCNC console. Notably, the legacy hal_manualtoolchange script does allow the user to bring focus to the GUI (whether Axis or Gmoccapy) and perform on-screen jogging and touch-off. Since the current Master hal_manualtoolchange script does not allow manual intervention (for what may well be sound reasons), it is the intention to apply any relevant code enhancements of the current script in the retained legacy script, to allow the required manual intervention.

With z-touch-off defaults of 50mm (rather than zero for Axis, Gmoccapy), we may fit two pushbuttons to our spindle sub-assembly for touch-off and tool change confirmation, avoiding the necessity to return to the console to proceed with machining after tool change (with some script, a single button might achieve both).

The legacy manual tool change script has been adapted to make window title and annunciations GUI-agnostic, and certain code changes there or elsewhere may be required to set z-touch-off default to 50mm. Perhaps there are Gmoccapy prefs and Axis defaults settable for this parameter.

As alluded to in second paragraph above, the legacy hal_manualtoolchange has indeed been tested to work as desired with Gmoccapy GUI (without pendant integration), provided in floating window mode. As noted in prior discussion, this approach is compromised by bottom row GUI buttons being mostly off-screen (although as RodW has noted, this may be a Debian constraint).

While not possible on-screen in Gmoccapy full-screen mode, the possibility of fixed tool change position with a single button to confirm manual toolchange in conjunction with Gmoccapy-intrinsic manual tool change script is kept in mind - but fixed tool change position is a disadvantage for a large machine table, potentially staging more than one job (table space allowing) concurrently.

Having 'come full circle' on this matter, perhaps another LCNC variant will arise - unless already out there but overlooked by this 'intermittent novice' forum member! It's beginning to motivate a branch specifically for this avenue of LCNC personality, rightly addressed under new topic.
More
24 May 2017 11:41 #93588 by rodw
rodw replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
Not up with Linux coding but in Windows there is a modal window that is forced to the foreground regardless. If you can't use the gmoc constructs, maybe the equivalent python modal construct will work. In practice though this window can open on the wrong monitor in a multi monitor situation. There seems to be a few ways to achieve this but it looks like if you Google "python modal window" you might find a solution.
More
25 May 2017 12:15 #93612 by andypugh
andypugh replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
I wonder if automatic tool-length probing would be a solution for you? It is reasonably straightforward to remap the tool-change process to automatically take the tool to a permanently-mounted probe, measure the tool, and then continue accordingly.
More
25 May 2017 18:49 #93629 by hwylie
hwylie replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
The suggestion of permanently mounted probe may be the way to proceed, if constraining machine use by the requirement to move to a fixed probe point, avoiding the danger of spindle traversing from work in progress over another job (or material in preparation) in order to probe - an infrequent scenario, although the large table lends itself to such.

It's anticipated that a single tool table can be used, provided that a custom fixture has associated coordinate system z-origin offset. Is this the direction of suggested investigation (having only briefly reviewed the suggested external-offsets github branch)?

Pointers to good examples of 'moveoff' or similar applications which move the spindle to fixed (G53) x-y coordinates of a probe following manual tool change, and return to G54 (or other) workpiece coordinates will be helpful.

Thank you, to both respondents.
More
25 May 2017 18:57 #93630 by andypugh
andypugh replied the topic: GMoccaPy doesn't fit in 1024x768 resolution
Look at the sample configs, specifically sim->axis->remap->manual-toolchange-with-tool-length-switch

(You should be able to start and run if from the config picker, it won't try to move hardware, so feel free to experiment)
The following user(s) said Thank You: hwylie
Moderators: newbynobi
Time to create page: 0.121 seconds
Powered by Kunena Forum