When homing, z bed moves down before going up, crashing into brackets

Hey guys,

Just got my SmartrapCore printer up and running with the latest version of Marlin.

However, when I home the axes, my bed lowers 10-15mm before the x and y axes home. Although occasionally the x and y axes will home before the z axis moves at all, yet regardless the bed moves down a small amount before going up.

This is an issue because my bed is always at the lowest position possible when I start, so this causes it to crash into the brackets holding the z-rods in place. So then the motor is skipping and that belt is freaking out, etc.

So I am required to raise my bed by hand and hold it in place before homing so that it starts mid-axis.

Is there a setting I can change to fix this? I've also noticed that when I turn the printer on it shows the Z axis at -14.99 by default? So it thinks it's above it's zero position? So perhaps it tries to lower it 15mm before homing x and y?? I don't even know.

FYI, I have auto leveling enabled using an inductive sensor.

Thanks for the help in advance.

This is a classic problem with having only 1 end switch per axis. The software needs to raise the nozzle off of the bed before it tries to home X & Y. Otherwise, if the nozzle is touching or pressing against the bed, something is going to get damaged. But because there are not end switches on both sides of the axis the machine has to make an assumption that it is OK to raise the nozzle.

You have a couple of options. You can add a Z-Max end stop so the machine knows where the end of travel is on that side of the axis. Or, you could leave the machine with enough room to perform its cautionary nozzle raise when it powers up. Or, you could set the Z-HEIGHT-For-HOMING to 0.00 if you know you won't leave the nozzle pressed against the bed.

Quote
Roxy
Or, you could set the Z-HEIGHT-For-HOMING to 0.00 if you know you won't leave the nozzle pressed against the bed.

Setting Z_HOMING_HEIGHT to 0 doesn't stop this behavior. It still tries to move to the greater value between Z_PROBE_DEPLOY_HEIGHT or Z_PROBE_TRAVEL_HEIGHT. I have not tried setting them all to 0, but I know if I set Z_PROBE_DEPLOY_HEIGHT to 0, it then moves the height set in Z_PROBE_TRAVEL_HEIGHT.

In RC6 you could issue a G92 Z160 before the G28 homing code and it wouldn't do it. Since RC7 has been released, the workaround doesn't work. You could do what I did and go through the source code and delete all the stuff moving Z before XY homing.

It seems the Marlin firmware is now assuming everyone uses a Z axis that does not sit at max travel during a power-off. The smartrapcore designs use a belted Z axis which falls to the floor on a power-off, which means when you first home it with G28 after a power-up Marlin tries to lower the bed further causing the belt to skip teeth.

Setting a few of the Z height variables to anything but 0 still result in this behavior, and a Z height of 0 screws up the up and down for probing.

But, I got fed up with the massive changes in the Marlin firmware release candidates and what seem to be incorrect assumptions regarding what has to happen on every machine with probing and switched it over to Repetier firmware. I can't say its any better yet, as I haven't had a lot of time to set it up and put it through the ringer.

Quote
PDBeal

You could do what I did and go through the source code and delete all the stuff moving Z before XY homing.

Where is that located? I'd like to look into doing that rather than installing a Zmax endstop.

Depending on what version your currently doing it sort of changes, but if you look in Marlin_main.cpp and search for "void gcode_G28()" That is the routine that handles homing. And if you skim through it until you see something similar to the following:

      if (home_all_axis || homeX || homeY) {
        // Raise Z before homing any other axes and z is not already high enough (never lower z)
        destination[Z_AXIS] = LOGICAL_Z_POSITION(Z_HOMING_HEIGHT);
        if (destination[Z_AXIS] > current_position[Z_AXIS]) {

          #if ENABLED(DEBUG_LEVELING_FEATURE)
            if (DEBUGGING(LEVELING)) {
              SERIAL_ECHOPAIR("Raise Z (before homing) to ", destination[Z_AXIS]);
              SERIAL_EOL;
            }
          #endif

          do_blocking_move_to_z(destination[Z_AXIS]);
        }
      }

That was the section I commented out at one time from the RCBugFix-RC7 version. It was different in the RCBugFix-RC6 version, so it might not look exactly like that depending on what version your using.

There might be another location to look too, but I don't remember if it was just the one section.

Edited 1 time(s). Last edit at 08/23/2016 09:27AM by PDBeal.

Quote
PDBeal
Depending on what version your currently doing it sort of changes, but if you look in Marlin_main.cpp and search for "void gcode_G28()" That is the routine that handles homing. And if you skim through it until you see something similar to the following:

      if (home_all_axis || homeX || homeY) {
        // Raise Z before homing any other axes and z is not already high enough (never lower z)
        destination[Z_AXIS] = LOGICAL_Z_POSITION(Z_HOMING_HEIGHT);
        if (destination[Z_AXIS] > current_position[Z_AXIS]) {

          #if ENABLED(DEBUG_LEVELING_FEATURE)
            if (DEBUGGING(LEVELING)) {
              SERIAL_ECHOPAIR("Raise Z (before homing) to ", destination[Z_AXIS]);
              SERIAL_EOL;
            }
          #endif

          do_blocking_move_to_z(destination[Z_AXIS]);
        }
      }

That was the section I commented out at one time from the RCBugFix-RC7 version. It was different in the RCBugFix-RC6 version, so it might not look exactly like that depending on what version your using.

There might be another location to look too, but I don't remember if it was just the one section.

So yes, that is exactly as it appears in my Marlin_main.cpp but commenting that out didn't change anything. I searched for other places that may have referred to it but couldn't really figure it out. Thanks for the help anyway!

I think the main issue is this: when I start my printer it thinks it's at (0, 0, -14.99) so when homing begins, it moves my bed down 15 mm before going back up toward the nozzle and endstop.

Commenting out those lines of the code prevented it from moving a couple mm to make room for the nozzle before X and Y homed, but it still tried to go down 15mm when Z homed.

So only half of my problem was solved (ie the small movement was eliminated, but the really long 15mm movement remains).




SO. Anyone know why my printer defaults to (0, 0, -14.99) at the start? Is there a way to set it's starting coordinates?

Quote
ryandgarrison
SO. Anyone know why my printer defaults to (0, 0, -14.99) at the start? Is there a way to set it's starting coordinates?

I asked that once myself and got no response. In RC6, I was able to do a G92 Z160 before it did a G28 which solved this because it was told it was far enough away, but in RC7 that stopped working which was when I commented out that section of code.

One thing you might have to do is set Z_PROBE_DEPLOY_HEIGHT to 0 down from 15. That's the part that is making your bed move 15 (I think).

I have the same problem on my corexy, any solution on this jet?

I just moved from Marlin 1.1.7 to 1.1.8 copying my settings over and while I never solved this problem on x.6 it seems it has gotten worse or "more unsolveable" on x.8.

Going to try commenting out the C code as a final resort here.

I commented out the code block above and that fixed the issues when homing X and Y but Z will still try and go down before up so you also need to comment out:

do_probe_raise(_Z_CLEARANCE_DEPLOY_PROBE);

and the issue is fixed. While not ideal, I have not found a magical combination of config settings that make this work. The other solution is to add the endstop but I really don't want my Z axis smashing into that everytime the motors lose power.

Anyhow, more documentation here: [github.com]

Best,
Andy