Homing issue

[dresco]

Hi Terje, have just updated my router to latest code, and seeing a weird homing issue.

Am running a ganged Y axis, with auto-squaring, on Phil's Teensy41 board. Was previously running code from much earlier in the year, didn't think to make of note of the older revision though.

Before attempting any movement, I'd moved the Y2 stepper & limit switch connections from B to A, and checked all the limit switches were triggering as expected in the realtime reports.

On each attempt to home; Z homes correctly as expected. If X is the next axis to reach it's limit switch, the switch is triggered, but the X axis motor doesn't stop. Stepper just stalls against the end stop. If the X axis limit switch is triggered when the Y axis reach their limit switches, then they stop as expected. If the X axis limit switch is not triggered when the Y axis reach their limit switches, then the Y axis motors don't stop. Stepper(s?) just stall against the end stops. If the Y axis limit switch(es?) are triggered when the X axis reaches it's limit, then X axis motor stops as expected.

Is a bit hard to tell whether it's affecting both or just one of the Y axis in each case.

Am building with platformio, no code changes, but have commented out the microSD libraries, and added the following settings;

    -DHUANYANG_ENABLE=1
    -DSPINDLE_RPM_CONTROLLED
    -DY_GANGED=1
    -DY_AUTO_SQUARE=1
    -DBLOCK_BUFFER_SIZE=512

Any ideas??

[terjeio]

I have just tested with my simulator and a Pro board and it works as it should. Wiring issue?

[terjeio]

Here are my limit pin assignments as reported by the $pins command:

[PIN:20,X limit min]
[PIN:21,Y limit min]
[PIN:23,Y limit min 2]
[PIN:22,Z limit min]

The same pins are used for T41U5XX and T14BB5X_Pro.

[dresco]

Thanks, yup my pins are the same. Is odd because the states all show up correctly in the ? report, just the motors don't stop when they trigger.

I've disconnected my stepper couplings now, so I can test with less panic :) I'll go back to a default build & settings, with no ganging/squaring & start from there.

[dresco]

Hmm, it's the following;

    -DHUANYANG_ENABLE=1
    -DSPINDLE_RPM_CONTROLLED

That causes an issue here without any ganging/squaring, seems that both X & Y limit switches need to be triggered (not necessarily together - one after the other is fine) before the motors will stop..

[terjeio]

This is strange, I just compiled with Huanyang spindle enabled and homing still works.

[dresco]

Would you be able to attach a working .hex, and I'll upload that as a sanity check? Thanks!

[terjeio]

Here is one for the T41U5XX board, I assume it is that you have. grblHAL_Teensy4_Upload.ino.zip

[dresco]

Thanks, this is super weird tho - am still seeing the same issue with your binary..

Think I'll have to sleep on it & hope for inspiration! Such a pain that there is no debug on this board :(

[terjeio]

If you have an USB <> UART breakout you can use that for "debugging", uncomment DEBUGOUT in grbl/config.h to enable debug_write (const char *s) - defined in grbl/stream.h. It claims the UART port so cannot be used with the Huanyang VFD.

[dresco]

Hi, have not worked out why yet, but the homing failure happens when grblHAL is not getting a response from the VFD (I hadn't wired it in yet for the initial movement tests)..

Did you say you had a spindle simulator in your setup? Now it's all connected, I can trigger the homing error just by changing the $374 baud rate to an incorrect value.

[dresco]

Is related to raising the spindle alarm, if I return 0 immediately from rx_exception() then the homing completes as expected..

[terjeio]

Is related to raising the spindle alarm, if I return 0 immediately from rx_exception() then the homing completes as expected..

Good catch - I'll have to look into this as it is not immediately clear to me what is going on when the spindle alarm is raised. For now you may try changing https://github.com/grblHAL/core/blob/d86015b154d21ba58d16189789a5f0ec16ccff13/limits.c#L206 to

if(sys.rt_exec_alarm || sys.alarm) {

If I am not mistaken this will terminate the homing sequence. But perhaps it should be allowed to complete? That could be tricky to handle though.

[dresco]

If I am not mistaken this will terminate the homing sequence.

Thanks, will try that tomorrow.

But perhaps it should be allowed to complete? That could be tricky to handle though.

I think just cancelling is infinitely better than unexpectedly crunching through the limit switches ;) Agree though that if you've got some sort of permanent vfd fault, would still be useful to be able to home the machine in that state.

It wasn't immediately clear to me why it was throwing a spindle error in the first place, but I see its turning off the spindle and coolant during homing, which makes sense now.

[dresco]

If I am not mistaken this will terminate the homing sequence.

Hmm, oddly it does not..

But perhaps it should be allowed to complete?

Had a thought on this, perhaps just make the stopping of the spindle/coolant conditional? (The get_state() non-blocking modbus timeout does not generate an exception)..

diff --git a/motion_control.c b/motion_control.c
index 50c7bf7..e515ac0 100644
--- a/motion_control.c
+++ b/motion_control.c
@@ -786,13 +786,17 @@ status_code_t mc_homing_cycle (axes_signals_t cycle)
 #endif
         hal.limits.enable(false, true); // Disable hard limits pin change register for cycle duration

-        // Turn off spindle and coolant (and update parser state)
-        gc_state.spindle.rpm = 0.0f;
-        gc_state.modal.spindle.on = gc_state.modal.spindle.ccw = Off;
-        spindle_set_state(gc_state.modal.spindle, 0.0f);
+        // Turn off spindle and coolant if needed (and update parser state)
+        if (hal.spindle.get_state().on) {
+            gc_state.spindle.rpm = 0.0f;
+            gc_state.modal.spindle.on = gc_state.modal.spindle.ccw = Off;
+            spindle_set_state(gc_state.modal.spindle, 0.0f);
+        }

-        gc_state.modal.coolant.mask = 0;
-        coolant_set_state(gc_state.modal.coolant);
+        if (hal.coolant.get_state().mask) {
+            gc_state.modal.coolant.mask = 0;
+            coolant_set_state(gc_state.modal.coolant);
+        }

[terjeio]

For now replace system_raise_alarm() with this code:

void system_raise_alarm (alarm_code_t alarm)
{
    if(state_get() == STATE_HOMING && !(sys.rt_exec_state & EXEC_RESET))
        system_set_exec_alarm(alarm);
    else if(sys.alarm != alarm) {
        sys.alarm = alarm;
        state_set(alarm == Alarm_EStop ? STATE_ESTOP : STATE_ALARM);
        if(sys.driver_started || sys.alarm == Alarm_SelftestFailed)
            report_alarm_message(alarm);
    }
}

[dresco]

For now replace system_raise_alarm() with this code

Thanks, can confirm this halts homing (after Z: is homed) when the spindle is unreachable..

[terjeio]

FYI I'll add the conditional check you proposed in the next commit as well.