GMoccaPy doesn't fit in 1024x768 resolution

Hi Nobert,

Sent the last week playing around with gmoccapy, ngcgui, Andys Lathe macros (haven't got Features installed yet). I relly like the gmoccapy interface. Thanks for sharing that.

It looks like the default gmoccapy window is about 1000x768. Since debian has tool bar across the top of about 20 pixels, gmoccapy doesn't quite fit on my 1024x768 15" screen.

how can I either:
1/ remove the debian tool bar (F11 for a web browser)
2/ resize gmoccapy to about 1024x740 to fit the standard screen size?
Mark

Gmoccapy has a settings page, there you can configure the display types and sizes.

Please read the manual for details.

Norbert

Sorry about that. I had been in there and changed the resolution, but hadn't noticed the "Full Screen" option.

Different question, which lathe canned cycles generator is easiest to install in gmoccapy?
1/ NCGgui
2/ Features - Lathe
3/ Andy's Lathe MAcros?
4/ None are really working with gmoccapy?

Mark

All should work with gmoccapy, but as Andy mentioned, you may need to adapt some stuff.
I had no problems with features, not tested Andy's part nor NCGui, as I do use my own code, just as macros integrated in the MDI page, or some remapped code. But that part of the code, I am not willing to share, as it contains some major brain stuff and is not usable without proper documentation.

Norbert

Thanks for the feedback guys.

I used to use TurboCNC, and it had a very simple G77 canned cycle. Amazing how much lathe work that one simple cycle could cover.

G77 Turning/Boring/Milling Cycle
Function: Turning with multiple passes, infeeding by an amount set by the I word.
Syntax: G77 [repetitive axis] [infeed axis] [feed per pass] [optional feed rate]
Example:
G77 Z-1.250 X0.250 I0.050 F5.0

Notes:
The order of the operands defines the motion. The back-and-forth action will occur from the current position of the first axis on the line to the position specified. The second axis called out will eventually reach the position specified by feeding in increments of I each pass.
The sign of I is unimportant. Always use I for the infeed, no matter what other axes are being used.
Infeed is applied to the second axis on the line. Creative use of this command can be made for fly cutting / slab-milling or cutting deep blind slots on mills or trimming the edges of stock.
After each pass, the control "backs off" by 1 1/2 times the infeed. So if you're boring, make sure you have enough clearance for the bar.
If the infeed doesn't divide into an even number of passes, a small finishing pass will be taken.


I need to reactivate my old 7x lathe conversion and use it to try out different GUI's and see which works best for me.

Mark

I wish to use the Gmoccapy GUI and have the same problem as original post. The Gmoccapy settings page enables the user to increase window height, but not make it less than 750 -- in order to see more than roughly half of the buttons at bottom of the GUI (Debian Wheezy, LCNC Master, 1366x768 monitor).

Gmoccapy full screen makes the bottom-row buttons fully visible as expected, but introduces the problem of manual tool change confirmation window focus described in my earlier post today (May 22).

Is it a consideration to adapt Gmoccapy screen height minimum value to something less than 750? I anticipate ~700 will make the window ('start as window'/'start maximised' as opposed to 'start as full-screen') visible on screen - to allow focus to be returned to confirm manual tool change, once necessary jogging and touch-off have been performed.

Alternatively, is there a workaround to allow Gmoccapy to overlay the Debian top toolbar?

Rereading your post, I am wondering if your issue is not a Debian issue?

I'll have to fire up my old monitor to check but its 4:3 format and I'm sure it is 1024 x 768. Using Linux Mint, I've had no problems with window sizing full screen or otherwise.

I recently purchased a wide screen 16:9 touch screen touch monitor in preparation for going live.

Now I'm not suggesting you just blindly go off and install Mint, but it might be worth investigating this a bit further.

A touch-screen is a consideration, once confident we'll get the desired functionality. As AP has suggested in reply to my other post today, a button fitted to the spindle-housing sub-assembly is not an unlikely remedy.

In the meantime, the view of the Gmoccapy guru is anticipated.

Since you've been through the exercise, your recommendation of touch-screen monitor?