When this happens for me, the spindle is stopped and coolant is turned off. Gmoccapy will not stop in auto or MDI mode if one of the jog buttons is pressed. Only if the jog-increment is changed. The jog pin function exits without doing anything if the system is not in manual mode.
I don't think this is an issue with the underlying LinuxCNC code as it is doing what it is told. I think this is a potentially unintended behavior in Gmoccapy.
Interestingly I found I was still having issues after fixing my code and making sure there were no erroneous hardware inputs. The problem seems to have been in the decoder comp function. In it I was doing the following (simplified):
Code:
jog_inc_0 = 0;
jog_inc_1 = 0;
jog_inc_2 = 0;
switch(jog_val) {
case 0:
jog_inc_0 = 1;
break:
case 1:
jog_inc_1 = 1;
break;
case 2:
jog_inc_2 = 1;
break;
}
jog_inc_
x are the output pins from the hal comp file and one of them is always selected.
When the code was changed to this the problem went away:
Code:
switch(jog_val) {
case 0:
jog_inc_0 = 1;
jog_inc_1 = 0;
jog_inc_2 = 0;
break:
case 1:
jog_inc_0 = 0;
jog_inc_1 = 1;
jog_inc_2 = 0;
break;
case 2:
jog_inc_0 = 0;
jog_inc_1 = 0;
jog_inc_2 = 1;
break;
}
The original code has the effect of toggling the selected jog increment pin on and off every time the comp is run. My theory is that once in a while the UI sees the jog increment pin as a 0 instead of a 1. I assumed that the hal pins would only be updated on exit from the comp module but this does not seem to be the case.
I am sure I am re-discovering something that is documented somewhere
