Gmoccapy - A new screen for linuxcnc
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?
Please Log in or Create an account to join the conversation.
But for these lines, I have no attachment and am happy to postpone the github thing until another time.
Thanks for asking.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
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 )
Please Log in or Create an account to join the conversation.
I will check this and correct as soon as possibleDocumentation 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 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.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.
What is the bug? I have not noticed any till now.Bug fix in _init_axis_four( self ),
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 )
Norbert
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Should I wait for your fix, or just push the correction?
Norbert
Please Log in or Create an account to join the conversation.
The code I posted does fix the problem, but it is only a quick and dirty fix.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.