Gmoccapy will abort in auto mode if the jog-increment pins are changed
11 May 2021 22:20 #208592
by andypugh
Replied by andypugh on topic Gmoccapy will abort in auto mode if the jog-increment pins are changed
It might be a bug, but I will admit that it sounds like one that I have got used to in Touchy.
If I set up a feed from MDI, for example M3 S1000, followed by G1 F80 X-100. If I want to stop short of X-100 and come back without stopping the spindle, I can touch the "jog" button which exits auto mode, but leaves the spindle turning and coolant on. So I can then type a new feed straight in.
It's probably a bug, but I like it
If I set up a feed from MDI, for example M3 S1000, followed by G1 F80 X-100. If I want to stop short of X-100 and come back without stopping the spindle, I can touch the "jog" button which exits auto mode, but leaves the spindle turning and coolant on. So I can then type a new feed straight in.
It's probably a bug, but I like it
Please Log in or Create an account to join the conversation.
11 May 2021 23:42 #208602
by ZincBoy
Replied by ZincBoy on topic Gmoccapy will abort in auto mode if the jog-increment pins are changed
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):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:
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
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):
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;
}When the code was changed to this the problem went away:
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
Please Log in or Create an account to join the conversation.
Time to create page: 0.271 seconds