I don't see this topic addressed anywhere so I'll ask what I hope is a new question.  My I am setting up a homebrew printer roughly based on OrdBot frame and Repetier firmware / Host.  The bed is nearly level, but of course never completely so.  I am at the point now where, when extruding a "raft" (I think it's called) to begin printing a part, the extruder has a difficult time finding the Z=0 height.  When I place the extruder at the proper height and power cycle to set this location as 0 in the firmware / Host software, it of course moves to another X/Y coordinate to begin printing.  At this point, the extruder drops down and either scrapes the blue tape or digs into the bed.

(1) I "think" (this is actually a question) I need to know how to level the bed?  I've done a "Config / Level Delta / set P1 P2 P3 points", "Calculate Leveling", and M500 Store to EEPROM.  This doesn't appear to be sufficient. What else do I need to do in this area?

(2) How do I tell the firmware / Host software where Z=0 is?  I don't have a Z probe, this doesn't seem to be a necessity, is it?

Thanks again for your help.


  • The esiest solution is when you have a max z endstop and lcd. Then you have a menu configuration->z-calib to do that. Just home, move z to bed and click on set z=0. You need to do this AFTER you have leved your bed manually. The autoleveling stuff does not work for you if you have no z probe, so make sure your experiments did not have it enabled.

    Afterwards you may tweak z-length in eeprom to adjust a bit when prints show z=0 is still not perfect.

    If you have a z min endstop things get more complicated. You need to level your bed manually. Then adjust the endstop position as long until home z stops where it should stop (without scraping blue tape).
  • Thank you for the response on the weekend!  Sorry to be dense, but I'm still confused.

    1. When I set the default to Z max endstop, the "Z home" function tried to take the extruder away from the bed (up as high as possible).  (Reversing Z motor direction did not reverse this process.)  Surely we're not leveling the bed with respect to running the Z height as far away from the bed as possible?

    2. I do have an LCD, but have not found a "set z=0" function in the firmware. Could you elaborate on where this is within the firmware menu structure?

    3. I have tried leveling the bed "manually" with a bubble level and assume I'm "close enough" for the firmware to compensate for the remainder.  Are you suggesting leveling the bed mechanically by adjusting bed height screws based, for example, on using a sheet of paper between nozzle and bed?

    I attempted to use a standard RepRap endstop PCB for a Z endstop and found considerable variance in the microswitch lever.  I am now constructing an endstop using a pushbutton switch cut from an old floppy drive.  I am not sure yet whether this will provide more accuracy than simply grinding off the lever from a RepRap circuit board.  Any experience in this area would be appreciated.

    Thanks again for all your help.  Your software is inspiring, both capability and creativity!

  • 1) Zmax is the fartest distance from bed. opposite to zmin so yes that is correct. For that reason we can fix errors in height just with changing z length.

    2) Requires zmax homing. Then should be in Configuration->Z Calib just as I wrote:-)

    3) Yes, screwa and paper works best. We are talking abount 0.1mm precision here!

    While x,y endstop precision is not that relevant z should be very precise ( <0.05mm). Switches can be that precise also not all are, but optical and hal endstops also work very well.
  • I'm attempting to disable the endstop checking in order to check the crosstalk issue.  But when I disable endstop checking, Z homing seems to not work.  And I think I need that in order to do the Config -> Z Calib -> Set Z=0. So assuming the Y bed shifting is due to endstop crosstalk, how do I set Z=0?
  • That function requires z max endstop. It changed the z length value by subtracting current z from current value.

    during homing endstops are always checked, you can not disable that. But you need a hardware endstop in the direction you home and firmware needs to know it is the endstop for that direction.
  • I understand those requirements.  So how does one address the crosstalk which occurs by having and enabling the endstops? I have twisted and separated the endstop cables but the Y bed drift continues.  I am replacing the endstop ribbon cables with shielded cable to see if that helps.

  • As I said 0.92.3 gives now a message when hit. Only way to see if that is the cause except disabling endstop test while printing.
  • Maybe my question is not being stated properly.  How can I use the Z=0 Config function, then turn off checking end stops during print, to find out if the crosstalk is causing the print shift?

  • I replaced the Ymin endstop ribbon cable with a shielded cable and unplugged Ymax and Xmax endstops.  I captured the following log.  I was watching this print closely.  There were Y steps missed which is why I hit Emergency Stop eventually.  But there is no way either the Ymin endstop or the Zprobe were triggered.  I would have noticed the LEDs on them. 

    How can I eliminate this error?  The printer is unusable with this error!  Please help.

    20:01:23.037 : N392 G1 X56.832 Y99.3 E524.4404 *116

    20:01:23.271 : ok 386

    20:01:23.271 : N393 G1 X54.472 Y96.938 E524.9956 *118

    20:01:23.646 : ok 387

    20:01:23.646 : N394 M105 *9

    20:01:25.818 : endstops hit: x_min:L y_min:H z_max:L Z-probe

    20:01:26.115 : ok 388

    20:01:26.115 : N395 G1 X50.7 Y93.166 E525.8828 *124

    20:01:26.146 : ok 389

    20:01:26.146 : N396 G1 X50.7 Y56.833 E531.9249 *118

    20:01:26.146 : ok 390

    20:01:26.146 : N397 G0 X51.1 Y56.999 F1800 *101

    20:01:26.740 : ok 391

    20:01:26.740 : N398 G1 X56.999 Y51.1 E533.3123 F900 *38

    20:01:29.193 : ok 392

    20:01:29.193 : N399 M105 *4

    20:01:29.318 : endstops hit: x_min:L y_min:L z_max:L Z-probe

    20:01:29.475 : ok 393

    20:01:29.475 : N400 G1 X93 Y51.1 E539.2993 *105

    20:01:29.787 : ok 394

    20:01:29.787 : N401 G1 X95.244 Y53.342 E539.8268 *113

    20:01:29.787 : ok 395

    20:01:29.787 : N402 G1 X98.9 Y56.999 E540.6868 *119

    20:01:31.365 : Printer reset detected - initalizing

    20:01:31.365 : start

  • To be clear - that Z=0 function is for calibration not nulling your z. It adjusts your printer height to be at zero after doing G1 Z0.

    The output shows especially the ymin gets triggered and this causes a y shift. Since you were watching that it was NOT really triggered it is cross talk that toggled the pin.

    What kind of endstop do you use? Also if you only connect 5V/gnd what voltage does the signal pin give when triggered/not triggered (works not with mechanical switches agains gnd). Especially optical switches do not have clear 0/5V signals so that it is easier to change the signal and also reflections could give wrong signals.

    Are there any cables near y min cable? I remmeber you said it happens only when printing so the guess is that extruder motor/heater cables share some path.
  • edited July 2015

    @Repetier, Thank you again for your support and continued patience with an obvious newby.  As I have said, and will continue to say, receiving support this responsive, detailed, and timely, one-on-one from another country is, in my opinion, astoundingly good.

    (1) Your last reply provides very interesting and helpful information.  I suspected, from your previous discussions on this forum, that my issue was crosstalk and examining the log verified this problem.  I now set out to correct it....

    (2) I am using mechanical endstops, standard PCB containing microswitches.  Triggering a Ymin endstop by hand, M119 (today) shows:

    15:41:38.268 : endstops hit: x_min:L y_min:H z_max:H Z-probe state:H

    However, upon examination I find the Signal pin on the endstop goes to GND when triggered.  Assuming the standard RAMPS 1.4 and the standard endstop PCB work together to provide this signal to the Arduino and the firmware sees the signal and (normally) behaves properly, is there a recommended way to invert this hard wired logic since you say (above) this is not a reliable method?

    (3) As I said, I replaced the Ymin cable with a shielded cable.  That is, all 4 wires are physically wrapped with a metallic shield, which is wired to GND on both ends of the cable.  While I have attempted to physically separate the endstop wires from the motor wires, they come in close proximity when connecting everything to the RAMPS PCB itself.

    (4) I am using a WYZworks Regulated Power Supply 12v 30a 360w for the system, and tried adjust the Y motor pot. I have not found a setting for this pot which makes the bed difficult to move by hand, which suggests to me that I need more current to the Y motor?  I have not the equipment to measure the voltage during motor movements, current to the motor during pulses, or capture and observe transient voltage spikes.  I also reduced acceleration parameters (to 600) and yesterday's test resulted in only a few dropped Y movements.  I consider this progress but still unacceptable as the print was significantly flawed.

    Since you so easily and correctly diagnosed this problem, there surely must be a solution because so many people are 3D printing successfully.  Again, I appreciate your attention and continue to believe in your product!

  • With mechanical endstop you normally have enabled pullup to pull the signal level to 5V when button is not closed.

    I'm not sure if this setting is correct if it is a switch with electroncis. Here I can not say what electronics does. It might be that using a pullup in that case is the wrong decision if it works agains the electronics.

    The normal solution is to twist motor and endstop cables. This way the induction switches direction over distance and levels it self out on average reducing the influence. The few cm on RAMPS are no problem for othe rprinters, so it shouldn't for you as well.
  • I seem to still be confused about homing and Z=0.  I do Calibration -> Set Z=0 (although I can't always allow a G1 Z0 to complete since it sometimes drives into the bed when Z=0 is wrong).  Next, I do Z home to Zmax endstop.  When next I do G1 Z0 (to start a print, for example), the head does not always return to Z=0 (or Z=0.4, etc).  I'[ve tried M500 and other ideas, but it feels like I must still be missing something in comprehending the overall process.

    Any ideas / further explanation would be appreciated.

  • All these commands do is changing z length in eeprom since that is the way you can go down after homing to z max. So for debugging the issue check what is the right value and how it changes by the commands you try.

    One more thing is the new bed coating function. Set coating height to 0 to eliminate influence from that since it influences z length computation dependent on your measuring mode set and coating height set.
  • Is this bed coating function in the firmware? What version should I be running? I have 0.92.3, but I fear I modified something other than configuration.h in order to get around the heater decoupling concerns. Would be nice if there was a way to create a .json file by decomposing an existing .h file
  • Bed coating is new in 0.92.4.

    We can not convert .h into config files, only if the config.h file was created with the tool. In that case it contains the json data needed at the end of the file.
  • I understand. It was a suggestion in the wrong forum. If we could parse the .h file to create (or validate) the info at the end of the file.
Sign In or Register to comment.