Gmoccapy will abort in auto mode if the jog-increment pins are changed

More
10 May 2021 03:44 #208452 by ZincBoy
I have been debugging an elusive issue with my mill. It has been randomly stopping in the middle of a program run and I think I found why.

My system has hardware buttons/knobs for most of the controls and one of the knobs is to change the jog increment value using the Gmoccapy HAL pins. A bug in my code meant that the debounce for this knob was not working and every once and a while it would glitch. The problem is that when this happened in auto mode (running a program), it would cause an abort and the program would stop.

I have confirmed this in simulation. Setting one of the gmoccapy.jog.jog-inc-X pins while a program is running will cause an abort.

To work around this, I have gated the jog-increment pins with the halui.program.is-auto signal so that the jog-increment can't change during auto mode. However, I don't think this is expected behavior. I would have expected the jog-increment pins to be ignored during auto and MDI modes and applied once the system switches to manual mode.

Please Log in or Create an account to join the conversation.

More
11 May 2021 22:20 #208592 by andypugh
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 :-)

Please Log in or Create an account to join the conversation.

More
11 May 2021 23:42 #208602 by ZincBoy
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_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:
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.

More
12 May 2021 12:36 #208619 by newbynobi
Hallo,

thanks for reporting, I am able to reproduce the behavior.
I do agree, that jog increment changes during auto mode should not lead to a complete stop.

I will check on this.

Norbert
The following user(s) said Thank You: andypugh

Please Log in or Create an account to join the conversation.

More
13 May 2021 11:38 #208725 by newbynobi
I just have pushed a fix to 2.8 repository for the misbehavior. (not in master!)

If you update to gmoccapy 3.1.3.2 the thing is solved.

Norbert

Please Log in or Create an account to join the conversation.

Moderators: newbynobiHansU
Time to create page: 0.057 seconds
Powered by Kunena Forum