Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware endstop don't work #1075

Open
nukem opened this issue Apr 1, 2021 · 5 comments
Open

Hardware endstop don't work #1075

nukem opened this issue Apr 1, 2021 · 5 comments

Comments

@nukem
Copy link

nukem commented Apr 1, 2021

Board: Due board.
Configuration.h

#define NO_SOFTWARE_AXIS_ENDSTOPS
#define X_HOME_PRIORITY 0
#define Y_HOME_PRIORITY 1
#define Z_HOME_PRIORITY 2

Configuration_io.h

ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, -1)
ENDSTOP_NONE(endstopXMax)
ENDSTOP_SWITCH(endstopYMin, IOEndstopYMin, Y_AXIS, -1)
ENDSTOP_NONE(endstopYMax)
ENDSTOP_SWITCH(endstopZMin, IOEndstopZMin, Z_AXIS, -1)
ENDSTOP_NONE(endstopZMax)

// Define all stepper motors used
STEPPER_SIMPLE(XMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopXMin, endstopNone)
STEPPER_SIMPLE(YMotor, IOY1Step, IOY1Dir, IOY1Enable, endstopYMin, endstopNone)
STEPPER_SIMPLE(ZMotor, IOZ1Step, IOZ1Dir, IOZ1Enable, endstopZMin, endstopNone)

I tested the pins if they do fire interrupts by including this on the main.cpp and blinking an LED and it does blink an LED.

#include "Repetier.h"
#include <SPI.h>

#if UI_DISPLAY_TYPE == DISPLAY_ARDUINO_LIB
//#include <LiquidCrystal.h> // Uncomment this if you are using liquid crystal library
#endif
void trigger_here() {
        HAL::digitalWrite(78, !HAL::digitalRead(78));
}
void setup() {
    Printer::setup();
    attachInterrupt(11, trigger_here, CHANGE);
    attachInterrupt(68, trigger_here, CHANGE);
    attachInterrupt(92, trigger_here, CHANGE);
}


void loop() {
    Commands::commandLoop();
}

Before commit b578234 only the X get triggered and it just crash on the Y.

Software endstop works ok.

@repetier
Copy link
Owner

repetier commented Apr 2, 2021

You are using the end stops wrong. You have added them as motor end stop here:
STEPPER_SIMPLE(XMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopXMin, endstopNone)
which should be
STEPPER_SIMPLE(XMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopNone, endstopNone)

You already defined them as axis end stop here:
ENDSTOP_SWITCH_HW(endstopXMin, IOEndstopXMin, X_AXIS, -1)

The motor end stops defined in drivers are for mirrored motors with multiple end stops.
Motor endstops only work if there is no
#define NO_MOTOR_ENDSTOPS

but with the pushing nature of the hardware end stops I wonder if that caused some different logic.

@nukem
Copy link
Author

nukem commented Apr 2, 2021

Probably forgot to remove it because I was trying to figure out why it's not working.

The X doesn't trigger if the carriage comes from a distant from the endstop. if the X is sitting on the endstop and does a home it is ok. I really wanted to use the interrupt driven endstop but it's not working.

I even tried to recreate the template code for endstop to check if I can attach an interrupt using the lambda method and it does work I can toggle a LED when I manually trigger the endstops.

template<int pin>
class Endstop {
    void_fn_t callbackFunc;
    fast8_t state;
public:
        Endstop(void_fn_t cb);
        void update();
        inline void attach();
};
template<int pin>
Endstop<pin>::Endstop(void_fn_t cb):state(false),callbackFunc(cb){}

template<int pin>
void Endstop<pin>::Endstop::attach(){
        attachInterrupt(pin, callbackFunc, CHANGE);
}

template<int pin>
void Endstop<pin>::Endstop::update() {
        HAL::digitalWrite(78, !HAL::digitalRead(78));
}

Endstop<68> yendstop([]() { yendstop.update(); });
Endstop<92> zendstop([]() { zendstop.update(); });
Endstop<11> xendstop([]() { xendstop.update(); });

void setup() {
    Printer::setup();
    xendstop.attach();
    yendstop.attach();
    zendstop.attach();
}
// EndstopSwitchHardwareDriver<pin, axis, dir> name([]() { name.updateReal(); });
//name([]() { name.updateReal(); })
void loop() {
    Commands::commandLoop();
}

It seems when the motor are in motion for a period of time that it doesn't recognize the endstops anymore.
I'll probably just use the software endstops since I am not running my printer for speed.

I have this on my configuration.h #define NO_MOTOR_ENDSTOPS so the motor endstops are ignored.

@repetier
Copy link
Owner

repetier commented Apr 9, 2021

I tested it on my printer and the hardware end stops worked. But during normal moves they are only checked if ALWAYS_CHECK_ENDSTOPS is enabled. Otherwise they will be ignored. Were you testing only with homing or also regular moves?

Distance should not matter for homing - it is only one move with 150% of size.

@nukem
Copy link
Author

nukem commented Apr 12, 2021

When the X is at home, it retest and works but the y and z doesn't. What I mean by distance is if the X is far from home and home axes is issued it fails 100%. I'll investigate it some more why it fails next week. It seems the interrupt somehow don't get attached or detached when moving or noisy wires not sure yet but the software endstop is working 100% so the lines are probably clean.

@repetier
Copy link
Owner

Software end stops are only tested every x stepper steps while hardware end stops are tested continuously. So if you suffer cross talk the hardware end stop will much more likely trigger than the software end stop.

Debug value 64 can be used to debug end stops. So send M111 S70 and you will see in log when and if end stop triggers. In case of cross talk it will do the back move not at the end but then it will do it. With SAFE_HOMING 1 it should then fail since it will not trigger again fast enough. With SAFE_HOMING 0 it will just stop at wrong position.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants