Can anyone explain this Makergear M2 Z-axis movement.

This is a question that I will be embarrassed I asked as I learn more but I really do need help with a quick start on my Makergear M2.
I bought the printer several years ago and made a small number of successful prints until the 3D printed motor mount broke and the printer was then put into storage since I did not have time to fix it. I now have a new metal motor mount in place and I am trying to get the printer back into operation.
As part of the restoration I did unplug the wiring on the Rambo board after I made notes and took photos of the original wiring connectors and then I restored the connections to their original position. I then tried to upgrade the firmware with Marlin which I am told was the original firmware but I did not like working with this so I changed to Repetier.  I now have logic problems.

The problem.

1. My M2 has the top mounted Z position sensor. On homing of the Z axis the bed moves up from the rest position to about the 50% of travel position and then stops followed by a normal X and Y homing. The bed is nowhere near the Z stop and the red LED at the sensor does not illuminate.

2. If I interrupt the above Z homing process by manually operating the Z sensor before the bed reaches the 50% position the Z axis movement stops, the red sensor LED illuminates and a correct X and Y homing takes place.

I am puzzled why the Z axis homing stops in the intermediate position clear of any sensor but the rest of the homing process thinks the Z axis is correctly homed.

There are multiple references to the Z axis in configure.h but rather than hacking a solution I would prefer to use the best practices for the configuration as I am sure can be recommended by the members.

Thanks for any insights you can provide.


  • Z axis move is 150% of the max. z distance, so normally enough. So you have one of these errors:
    - z max is wrong.
    - z axis steps per mm is wrong. Move e.g. 10mm and measure how much it really moved. Z differs much in steps per mm from x and y and if microsteps are not as expected they also can be off factor 2 or 4 or 8 from what would be correct.
    - you loose steps on z move - you hear this with a high pitch sound, but from description this is not your problem. If it becomes from changing second case reduce acceleration or z max speed.
  • Thanks Rep. I will be working on this in a couple of hours.
  • Rep,
    I tested your suggestions with interesting results but the problem is not cured. The adjustment to Z_MAX_LENGTH did not seem to do anything but changes to ZAXIS_STEPS_PER_MM did. The adjustment required what seems to be fairly large changes so I was cautious. As I increased to parameter value the bed did move from rest to a higher position in the frame. Eventually with a setting of 180 steps/mm the bed reached the Z sensor. This surprised me since the X and Y settings are 80 and 80. Measuring the bed height changes suggests that a 50 mm change request through the G-code settings results in a bed height change of about 25mm.

    I suspect the problems may be due to the fact the Z sensor is mounted at the top of the Z movement. Is this possible?

    Here are the parameters that seem to connect to the Z axis and their default values, do they seem OK?
    Z_HOME_DIR -1
    Z_MAX_LENGTH 120
    Z_MIN_POS 0

    Thank you for your time

  • Z axis is not using Belt, so steps vary very much. Often 1000 an more, that is normal. But as I said measure moved distance vs. what you said or do the math.

    4mm spindle, 200 steps Motor 16 Microsteps => 200 * 16 / 4 = 800 steps/mm. And there are spindles with 2mm/rotatio or drivers with 32 microsteps.
  • Got you thanks. I was getting nervous because the steps/mm were getting so much bigger than X and Y.
  • Rep. Thanks for the information it was a useful introduction to configuration.h which I did not have to use when the printer was new because the SD card contained a generic version of the settings. Now I know better.

    The printer is adjusted for bed level and bed height and it is working well although I see I will need feed and extruder temperature adjustments.

    On my first use I was able to use slic3r inside of Host but this seems to have failed and I get an error message of "

    19:11:04.577 : System.ComponentModel.Win32Exception (0x80004005): The specified executable is not a valid application for this OS platform. at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo) at SlicerSlic3r.Slic3rInstance.Slice(String[] files, String output)"

    I did not get much help on the internet so I will search the forum to see what I can find.

  • Bette ruse PrusaSlicer instead.
    Which OS are you using? Depending on OS the slicer might not be compiled for it. Hard to say since we do not compile them - we use the official version. You can also just download any other official version and in slicer manager you can set path to that executeable, then the external version gets used instead.
Sign In or Register to comment.