I have used Marlin for 10 years. I have edited the config file more times than I have kissed my wife.
I have a lot of experience, but I have no idea whats going on here.
The printer is a common configuration with a moving gantry for the X axis containing the hotend. On that gantry is also a servo activated Z-probe on an arm.
When I use Octoprint to move the Z-axis, down button moves down, up button moves up so the motor polarity is correct. I have also done this with G-codes to confirm operation.
The config file is set up with z homing direction -1 as normal with the define in place for seeking Z-Min.
THE PROBLEM is that homing causes the gantry to move UP instead of down towards the bed. It's even weirder than that. It moves up quite a bit and then the servo activates. I can usually get it to think it's done by pressing the Z_MIN switch a few times at that point.
It has to be a configuration problem, right? Here are some selected entries from the config file - the ones I am aware of that come into play.
#define USE_ZMIN_PLUG
#define Z_MIN_ENDSTOP_INVERTING true // Set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING true // Set to true to invert the logic of the probe.
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define USE_PROBE_FOR_Z_HOMING
#define Z_PROBE_SERVO_NR 0 // Defaults to SERVO 0 connector.
#define Z_SERVO_ANGLES { 27, 115 } // Z Servo Deploy and Stow angles
#define INVERT_Z_DIR false
#define Z_HOME_DIR -1
#define MIN_SOFTWARE_ENDSTOPS
#if ENABLED(MIN_SOFTWARE_ENDSTOPS)
#define MIN_SOFTWARE_ENDSTOP_X
#define MIN_SOFTWARE_ENDSTOP_Y
// #define MIN_SOFTWARE_ENDSTOP_Z
#define AUTO_BED_LEVELING_LINEAR
#define GRID_MAX_POINTS_X 3
#define GRID_MAX_POINTS_Y GRID_MAX_POINTS_X
#define VALIDATE_HOMING_ENDSTOPS
#define NUM_SERVOS 1 // Servo index starts with 0 for M280 command
If you have any personal experience with anything that looks like this, please let me know if you think I am doing anything wrong in config. If you do not have any specific wisdom, please do not respond (unless you are Mark).
It seems like a weird problem, but I know that I am doing something wrong. It works on my other machine, but that one runs Marlin 1.0 and I had to hack the bed leveling code into it manually back when it was new. Marlin 2 has way more configuration parameters and features which I am finding a little cryptic.
The endstop (probe) is a NO switch (to ground) with a 4.7k pullup.
I just know I'm going to feel stupid...
I tried via SSH.
Sudo make clean
sudo make
results in a million pages of output with this at the end.
That is an actual failure, right? How is it compiling in the web interface if it can't compile like this?
And it is doing it again. I was just finished changing steps per mm calibrations and tried a home. Goes up and doesn't stop or engage the servo.
I am tired of not seeing the compile output in the web interface. It is really uncomfortable and difficult to know that it is working. When I send M503, the values are not correct. If I send M502, the values are still not correct. It feels like I am not successfully making changes to the configuration, but I have no way of knowing since I cannot see the entire compile output.
After that, I tried compiling again and then M503 reported correct values. Also homing worked properly.
I think that unsuccessful compiling leads to bad homing operation, but I do not understand how the result of a bad compile would be attempting to run.
I also do not understand why compiling is only randomly successful.
Confused and frustrated.
EDIT: Confirmed that M502 DOES NOT bring back configuration.h values for steps/mm and accelerations. I MUST have made successful changes at SOME POINT since I was able to change many machine parameters like servo and temperature probes but the changes that I am trying to get into configuration.h right now are not being used or recalled by M502.
That's great! you have fixed that.I can understand that while debug some problems.
Yes, I was thinking about the bump up as well, but it would just continue up.
I made it work eventually by changing (rewiring) the polarity of the endstop/probe and putting the Z_MIN_PROBE_ENDSTOP_INVERTING back to false like the other endstops.
So, I have no explanation for the strange upward movement forever, but now it does what it's supposed to do and goes up a little bit, engages the servo and then starts down. It stops when the switch hits the bed and backs off.
The key to constraining the problem enough to work on it was realizing that G29 has nothing at all to do with G28 so I could ignore all the bed leveling defines.
Thanks, Mark and sorry that I can't explain the weirdness but I'm still pretty confident that it was real.
it seems strange! I normally change the INVERT_Z_DIR while the direction is wrong.
the Z axis will go up some distance before the servo activated, see Z_CLEARANCE_BETWEEN_PROBES ,but this value is just 5mm.
#define Z_CLEARANCE_BETWEEN_PROBES 5 // Z Clearance between probe points