repetier / Repetier-Firmware

Firmware for Arduino based RepRap 3D printer.
815 stars 734 forks source link

Software endstop don't trigger on retest #1073

Closed nukem closed 3 years ago

nukem commented 3 years ago

Software endstop stopped working on recent changes. It only triggers on initial test and gives out error on retest moves that it didn't trigger.

ENDSTOP_SWITCH(endstopYMin, IOEndstopYMin)

nukem commented 3 years ago

Here's the error message:

Warning:Endstop for axis X did not untrigger for retest!

I have an optical endstop.

repetier commented 3 years ago

Is this with commit "Fix safe homing for bouncing end stops" included. Before I had a similar problem so I introduced a history function. For simple switch this is updated here in endstops.cpp:

template <class inp>
inline bool EndstopSwitchDriver<inp>::update() {
    if (state != inp::get()) {
        state = !state;
        historyUpdate(state);
        if (Printer::debugEndStop()) {
            Printer::reportFlagSet(PRINTER_REPORT_FLAG_ENDSTOPS);
        }
    }
    return state;
}

This can also be a result of not going back enough also with optical end stops normally 1mm is enough.

BTW: For due you should use hardware end stops, they cost much less cpu time. That is also how I tested the new SAFE_HOMING flag which in the end causes your problem. But before the commit I had the same problem due to bouncing signal.

nukem commented 3 years ago

Yes before that commit my endstops are ok. One of the endstops can't be attached to an interrupt, I don't have much option on it since it's a commercial printer.

nukem commented 3 years ago

The hardware interrupt is ok because 2 of the endstops uses it. I reverted back to the old version of the files for now.

repetier commented 3 years ago

https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/ say all pins work with hardware interrupt.

Need to check this next time I upload the firmware switching to software end stop. But I use the same code in hardware endstop, so strange.

repetier commented 3 years ago

Ok could reproduce and find the problem. Software end stops do not update on moves without end stop check so historyWasUntriggered returned wrong result. Have now added a explicit update in that function for this case. Now works also with latest commit and safe homing.