Advanced Search

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.

The read ahead will start ingesting gcode again as soon as the touch off is completed and as soon as it reaches a command that would violate a limit the program will abort. This is happening well before actual execution of the queued motion commands.

Aha, another informative data/state dump would be:

halcmd show all ini.

 

I have been running gmoccapy with a joypad with RIP tag v2.9.2 for quite a while on my mill, router, and lathe.

When I check out and build branch 2.9 or tag v2.9.3 and RIP with the exact same mill.ini, I am now getting jog Y negative direction (slow/fast) actions whenever I press the btn-joystick and btn-thumb on my joypad. I have these two joypad buttons set up to select speed (wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_Remote_Pendant).  

I used hal watch to look at gmoccapy.jog.axis.joy-y-minus and it stays false when I press the buttons. If I do use the joy-y-minus set control it jogs at the same speeds(depending on turtle/rabbit) as when I press the joypad btn so the joypad buttons seems to be triggering the jog but I don't know how this gets mapped as there is nothing in my config that did that?

Looking at my gmoccapy.preferences
use_keyboard_shortcuts = False

I had to install version 4 of gtk something to get v2.9.3 to run, now I can't run run 2.9.2 anymore. 

Any help/hints would be appreciated.


 

Agreed on the "probe succeeding".

I added this in order to see what is taking place:
'Return to original tool-tip position using new z-offset: ...'

I've noted from the script that:
#<touch_result> = #5063
which equates to 277.16xx in this case. Fairly consistent thru the 3 attempts.

I'm attaching the script as I have it now including the extra debug messages.

It's worth noting that immediately after the second touch-off the program aborts. There is no movement for any axis.