Homing issue about core HOT 17 CLOSED

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

from core.

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

from core.

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.

from core.

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.

from core.

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..

from core.

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

from core.

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

from core.

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

from core.

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 :(

from core.

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.

from core.

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.

from core.

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

from core.

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

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.

from core.

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.

from core.

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);
+        }

from core.

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);
    }
}

from core.

For now replace system_raise_alarm() with this code

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

from core.