Homing breaks if a second axis home command is requested before the first completes homing.

[Lcvette]

linuxcnc 2.9.4 deb installation fully up to date
linux Debian 12 Bookworm, fully up to date
axis sim

I was asked if there was a bug in Probe Basic when requesting a second axis to be homed prior to the first axis completing its homing routine. I tested this in axis sim config to find that the bug is present there as well. the axis will actually move in the wrong direction indefinitely until user intervenes (no soft limits are active because homing fails to complete)

how to test:
I had to slow down the home_search and home_latch velocities to 0.1 in the ini for all axes in order to be able to trigger each axis before it completed and verify the bug.

select the x axis and press home key, then select y axis and press home key, the screen would freeze and then unfreeze and the homing process was then broken with the x axis moving away from the home switch.

not sure of a solution besides perhaps disabling any subsequent user homing requests while an axis is actively homing.

[rmu75]

Can confirm with current master and sim axis mm config with slowed down velocities.

After issuing second home command, screen freezes until first home completes, second home is hosed.

Component Pins:
Owner   Type  Dir                 Value  Name
    31  float OUT                     0  joint.0.acc-cmd
    31  bit   OUT                  TRUE  joint.0.active
    31  bit   OUT                  TRUE  joint.0.amp-enable-out
    31  bit   IN                  FALSE  joint.0.amp-fault-in
    31  float OUT                     0  joint.0.backlash-corr
    31  float OUT                     0  joint.0.backlash-filt
    31  float OUT                     0  joint.0.backlash-vel
    31  float OUT               32.1068  joint.0.coarse-pos-cmd
    31  bit   OUT                 FALSE  joint.0.error
    31  float OUT                     0  joint.0.f-error
    31  float OUT                 0.254  joint.0.f-error-lim
    31  bit   OUT                 FALSE  joint.0.f-errored
    31  bit   OUT                 FALSE  joint.0.faulted
    31  float OUT               1000.15  joint.0.free-pos-cmd
    31  bit   OUT                  TRUE  joint.0.free-tp-enable
    31  float OUT                   0.1  joint.0.free-vel-lim
    31  s32   OUT                     7  joint.0.home-state
    31  bit   IN                   TRUE  joint.0.home-sw-in <== XZhomesw
    31  bit   OUT                 FALSE  joint.0.homed
    31  bit   OUT                  TRUE  joint.0.homing
    31  bit   OUT                 FALSE  joint.0.in-position
    31  bit   I/O                 FALSE  joint.0.index-enable
    31  float IN                      1  joint.0.jog-accel-fraction
    31  s32   IN                      0  joint.0.jog-counts
    31  bit   IN                  FALSE  joint.0.jog-enable
    31  float IN                      0  joint.0.jog-scale
    31  bit   IN                  FALSE  joint.0.jog-vel-mode
    31  bit   OUT                 FALSE  joint.0.kb-jog-active
    31  float OUT               15.8496  joint.0.motor-offset
    31  float OUT               47.9564  joint.0.motor-pos-cmd ==> Xpos
    31  float IN                47.9564  joint.0.motor-pos-fb <== Xpos
    31  bit   OUT                 FALSE  joint.0.neg-hard-limit
    31  bit   IN                  FALSE  joint.0.neg-lim-sw-in
    31  float OUT               32.1068  joint.0.pos-cmd
    31  float OUT               32.1067  joint.0.pos-fb
    31  bit   OUT                 FALSE  joint.0.pos-hard-limit
    31  bit   IN                  FALSE  joint.0.pos-lim-sw-in
    31  float OUT                   0.1  joint.0.vel-cmd
    31  bit   OUT                 FALSE  joint.0.wheel-jog-active

[Sigma1912]

I've had a look at this.

inserting this check

        if ( get_homing_is_active() ) {
	        reportError("Homing not possible until current homing process is finished.\n");
                return;
	    }

here

linuxcnc/src/emc/motion/command.c

Line 1366 in 6cdd1ef

fixes the homing bug itself.

However it does not fix the Axis GUI freeze which comes from these two calls to 'wait_complete()' timing out to the default 5 seconds:
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/scripts/axis.py#L1954
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/scripts/axis.py#L280

changing the two calls to 'wait_complete(0.1)' makes the freeze go away but that seems a bit clumsy a fix.

[Sigma1912]

I guess something like this:

def go_home(num):
    s.poll()
    for j in range(s.joints):
        if s.joint[j]["homing"]:
            print(_("\nHoming not possible until current homing process is finished"))
            return
    set_motion_teleop(0)
    c.home(num)
    c.wait_complete()

[andypugh]

@Lcvette This may need modifications to ProbeBasic analogous to those in Axis and Gmoaccpy.

[rmu75]

I've had a look at this.

inserting this check

        if ( get_homing_is_active() ) {
	        reportError("Homing not possible until current homing process is finished.\n");
                return;
	    }

is this really the right fix? why shouldn't it be allowed to home 2 joints at the same time? it definitely is possible in the normal homing sequence.

[andypugh]

With a homing sequence the a es all start at the same time, even if they don't finish at the same time. There might be a better fix that allows homing to be sequenced manually, but I can't think that there is much demand given that there isn't much complaint about it not working.

[Sigma1912]

Yes the problem is that joints that are not part of the current sequence are ignored even if they are already in the process of homing. I did actually spend a fair bit of time trying to fix this in homing.c . I even got it working but it ended up braking other things and it didn't fix the gui freeze either. In the end it didn't seem worth the risk of breaking something else.