Gmoccapy - A new screen for linuxcnc

Thanks, and sorry for the slow reply. I am currently working 5000 miles from home, and don't have as much spare time as normal.

Are you interested in making further contributions to LinuxCNC, or do you see this as a one-off? In the latter case I can incorporate it as a patch on your behalf, and send it through the normal approval channel.
If you feel you might want to continue to contribute then you could consider setting up a local git repository and pushing directly to GitHub in your own right.

Which do you prefer?

I do like my name on creations I am proud of.
But for these lines, I have no attachment and am happy to postpone the github thing until another time.

Thanks for asking.

Norbert,

A couple of things:

Documentation for 2.8 (master) has pin names which appear to have changed in new versions of gmoccapy.
gmoccapy.reset-spindle-override is now gmoccapy.spindle.reset-spindle-override
gmoccapy.reset-feed-override is now gmoccapy.feed.reset-feed-override
(from memory, I'm away from my CNC pc).

Is the information regarding XZ + C lathe from forum.linuxcnc.org/gmoccapy/30175-xz-lat...xis-gmoccapy-crashes still relevant in lastest gmoccapy? If so, can you include it in the documentation?
I ran into this problem on 2.7.11, but have since changed to master and have not tried this setup again.

Once again, thanks for gmoccapy - it is an awesome GUI.

Bug fix in _init_axis_four( self ),

Documentation for 2.8 (master) has pin names which appear to have changed in new versions of gmoccapy.
gmoccapy.reset-spindle-override is now gmoccapy.spindle.reset-spindle-override
gmoccapy.reset-feed-override is now gmoccapy.feed.reset-feed-override
(from memory, I'm away from my CNC pc).

I will check this and correct as soon as possible

Is the information regarding XZ + C lathe from forum.linuxcnc.org/gmoccapy/30175-xz-lat...xis-gmoccapy-crashes still relevant in lastest gmoccapy? If so, can you include it in the documentation?
I ran into this problem on 2.7.11, but have since changed to master and have not tried this setup again.

I have not tested, but IMHO it is not possible to have a machine with that configuration, as gmoccapy expect the first 3 coordinates to be XYZ. I am not sure, if it does worse to include such configs, but I will check how much work that would be to include.

Bug fix in _init_axis_four( self ),

Code:

for axis in self.axis_list: self.widgets["Combi_DRO_%s" % axis].set_property( "font_size", self.dro_size ) if self.get_ini_info.get_lathe(): # There is a bug here that I am patching. self.widgets["Combi_DRO_%s" % 'y'].set_property( "font_size", self.dro_size )

What is the bug? I have not noticed any till now.

Norbert

The bug is that in lathe mode, if I change the DRO font size in the settings page, only the R and Z axes changes size. The D axis font size is unaffected.

OK, I can reproduce that one.
Should I wait for your fix, or just push the correction?

Norbert

Don't wait for me.
The code I posted does fix the problem, but it is only a quick and dirty fix.

I just pushed a bugfix for the DRO Size bug in lathe mode reported from Partic T.
Thanks Patric for reporting.

The bug fix was applied to 2.7 and master.

Norbert

P.S. Next will be the documentation update for master

Hello,
when I am using a non-integer G54 offset, the preview is offset by the non-integer part of the offset compared to the tool trace (see attached image ...offset1.png) With integer G54 coordinates, the offset is gone (..._no_offset.png). I observed this with gmoccapy 1.5.8 on lcnc 2.7.11 and with gmoccapy 2.3.3.2 on lcnc 2.8.0~pre. Am I doing something wrong or is this a known issue?
Greetings,
Karl

P.S. there is no offset when using the axis GUI
P.P.S found the solution: this happens only in the LANG=de_DE.utf8 setting and disappears in LANG=en_US.utf8, so it seems to be a mixup in the decimal delimiter evaluation. Sorry for the "spam", but it still looks a bit buggy to me.