DouglasPearless / Smoothie2

(Attempt at) A Smoothie firmware port to the Smoothieboard v2 boards.
GNU General Public License v3.0
0 stars 0 forks source link

Endstops are ignored when homing (G28) #4

Open DouglasPearless opened 7 years ago

DouglasPearless commented 7 years ago

G28 does not stop when the unstops are reached.

DouglasPearless commented 7 years ago

This is due to the SlowTicker timer not firing when it should and appears to be a priority issue, still under investigation.

DouglasPearless commented 7 years ago

What I have determined is that unless the slow_ticker NVIC priority is raised to the the same as the set_ticker, it never fires at high step rates.

I raised it to the same priority as the step_ticker and then noticed that the step_ticker "stretches" by the duration of the slow_ticker hooked read_endstops() call.

Something a bit weird is happening here and needs further investigation as the stretching by the stow_ticker implies that the step_ticker TIMER0 is not operating as I had expected during interrupts; I need to better understand the clock generation and timer interrupts and interrupt groups on the processor :-)

The picture here doesn't really show it that clearly, I will take a better one tomorrow:

screenshot from 2016-11-15 23-44-12

DouglasPearless commented 7 years ago

The end stop detection is working much better, but the last arm to home (i.e. the effector end was not at X=0, Y=0 so one of the three arms has longer to travel) always backs off the endstop too much, need to figure out why this is.

screenshot from 2016-11-17 23-26-23 - alpha endstop

DouglasPearless commented 7 years ago

For some strange reason the G28 (HOME) is always in the opposite direction of the normal G0 commands, so when the DIR pins are inverted, the G0 works correctly, but the G28 (HOME) goes toward the min end-stops even though it is configured for the max end-stop on a RotaryDelta; rather puzzling.

DouglasPearless commented 7 years ago

I have been debugging this weird homing issue and irrespective of whether the delta[Z_AXIS] is a positive or a negative number, it always moves away from the endstops:

Same code taken from endstops.cpp for my Rotary Delta:

    if(axis_to_home[Z_AXIS]) {
        // now home z
        float delta[3] {0, 0, gamma_max}; // we go the max z
        if(this->home_direction[Z_AXIS]) delta[Z_AXIS]= -delta[Z_AXIS];
        THEROBOT->delta_move(delta, fast_rates[Z_AXIS], 3);
        // wait for Z
        THECONVEYOR->wait_for_idle();
    }

I must admit this is very weird.