Z drops into bed at start of printing

I'm using RAMPS 1.4 and Marlin. I used Marlin-Development 03-29-2015 as well as Marlin 1.0.2.1

I don't use Auto Leveling!

I set the nozzle to paper height on all four corners and center bed. I start printing and the bed heats up. When the extruder starts heating the bed homes. So far it's normal. Once the extruder reaches temps and the printing starts the print head moves to the center to start printing and drops into the bed. It hits the limit switch and keeps going down crashing the limit switch. Luckily the two z screws were not tight and they lifted up a few mm, or the switch would have been broken, and the bed squished down a bit. The printing continued, the nozzle scraping the bed and the LCD shows z height of 0.2mm, the height of my first layer. I disconnected the power to the printer. After turning it on again I moved the z axis up, in Pronterface. It went up about 4mm before it got to the normal position. That is the screws went down and the bed came up to the normal position.

I know it's somewhere in the Marlin setup but I'm not sure where.

Quote
I set the nozzle to paper height on all four corners and center bed

Do you mean when the printer homes Z to 0, or are you moveing Z manually after it has homed ?

What I mean it that when the printer starts to print it drops into the bed.

The bed was leveled using the paper thickness setup. That means that Z 0 is when the nozzle touches the bed and the paper is just rubbing when pulling out, which is the normal setup.

Now I start printing. The bed heats up. When it reaches it's temps the printer homes all axis'. So far so good. Now the extruder heats up and when it reaches it's temps Z goes up to 5mm and the head and bed move so the nozzle is at the start point of the print. So far it's working like normal. Now the nozzle goes down to start printing but instead of dropping to the Z 0, that I've set up, it drops way below it, maybe 4 or 5 mm. It crashed into the limit switch but the limit switch is not preventing it from going farther down electrically but physically since the gantry is resting/crashing the limit switch.

It looks like the limit switch is disabled once printing starts but that is not as important as why is the program tells the gantry to go down farther than the set Z 0 point.

A possibility there is a command in your slicer start up G-code. Look there.

Edited 1 time(s). Last edit at 02/06/2017 01:00PM by Shank man.

When you home Z to 0. then send a M114 from pronterface, does it say that Z is actually 0.

Quote
Shank man
A possibility there is a command in your slicer start up G-code. Look there.

I did and there is no wrong command. Besides, shouldn't the home/limit switch stop it from going to low? It looks like the limit switch is disabled once the printing starts.

Quote
obewan
When you home Z to 0. then send a M114 from pronterface, does it say that Z is actually 0.

I'll try it and will post my findings.

Tried it and it reported all axis' 0.000.

The only two files that I changed are the configuration.h, had to put my settings for the axis' and the pins.h to have the LCD run reverse, line going down on the display when the knob is turned CW.

Edited 1 time(s). Last edit at 02/06/2017 07:14PM by JustinTimeToo.

Slic3r used to include a nozzle lift command in the startup g-code
if you see that line after the home axes command get rid of it. All it does
is cause the Z to over ride the limit switch and plunge the nozzle into the bed



also check your firmware settings to see if these lines are defined.

#define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below.

// Travel limits after homing
#define X_MAX_POS 160
#define X_MIN_POS 0
#define Y_MAX_POS 155
#define Y_MIN_POS 0
#define Z_MAX_POS 95
#define Z_MIN_POS 0

#define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS)
#define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS)
#define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS)


if your printer is homing correctly than the problem lies in your G-code generated to start the print. Open the g-code
in a text editor and the Z drop command should be in the first few lines. Here is a snippet of some print g-code.


; generated by Slic3r 1.1.7 on 2017-02-05 at 14:34:09

; perimeters extrusion width = 0.25mm
; infill extrusion width = 0.35mm
; solid infill extrusion width = 0.35mm
; top infill extrusion width = 0.35mm

G21 ; set units to millimeters
M106 S0
G28 ; home all axes


G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion
G1 F1800.000 E-1.00000
G1 Z1.150 F7800.000
G92 E0
G1 X30.237 Y30.893 F7800.000
G1 Z0.150 F7800.000 (check to see if Z is a negative number. you can change this. save & reload to host)
G1 E1.00000 F1800.000

Edited 1 time(s). Last edit at 02/07/2017 05:51AM by Shank man.

Quote
Shank man
Slic3r used to include a nozzle lift command in the startup g-code
if you see that line after the home axes command get rid of it. All it does
is cause the Z to over ride the limit switch and plunge the nozzle into the bed

[attachment 90110 start_gcode.jpg]

Yes, it has this command. I commented it out as you suggested and it still does the dropping

Quote

also check your firmware settings to see if these lines are defined.

#define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below.

// Travel limits after homing
#define X_MAX_POS 160
#define X_MIN_POS 0
#define Y_MAX_POS 155
#define Y_MIN_POS 0
#define Z_MAX_POS 95
#define Z_MIN_POS 0

I have those set the same way

Quote

#define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS)
#define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS)
#define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS)

I don't have this code. I don't think that is a problem since it just tells the max travel per axis.

Quote

if your printer is homing correctly than the problem lies in your G-code generated to start the print. Open the g-code
in a text editor and the Z drop command should be in the first few lines. Here is a snippet of some print g-code.


; generated by Slic3r 1.1.7 on 2017-02-05 at 14:34:09

; perimeters extrusion width = 0.25mm
; infill extrusion width = 0.35mm
; solid infill extrusion width = 0.35mm
; top infill extrusion width = 0.35mm

G21 ; set units to millimeters
M106 S0
G28 ; home all axes


G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion
G1 F1800.000 E-1.00000
G1 Z1.150 F7800.000
G92 E0
G1 X30.237 Y30.893 F7800.000
G1 Z0.150 F7800.000 (check to see if Z is a negative number. you can change this. save & reload to host)
G1 E1.00000 F1800.000

Yes, my gcode looks like this too except that I have the G1 Z5 but I have it commented out as you can see below

Quote

; generated by Slic3r 1.2.9 on 2017-02-02 at 17:14:41

; external perimeters extrusion width = 0.40mm
; perimeters extrusion width = 0.67mm
; infill extrusion width = 0.67mm
; solid infill extrusion width = 0.67mm
; top infill extrusion width = 0.67mm

M107
M190 S100 ; set bed temperature
M104 S235 ; set temperature
G28 ; home all axes
; G1 Z5 F5000 ; lift nozzle

M109 S235 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
G1 Z0.200 F7800.000
G1 E-5.00000 F2400.00000
G92 E0
G1 Z5.200 F7800.000
G1 X80.181 Y80.854 F7800.000
G1 Z0.200 F7800.000
G1 E5.00000 F2400.00000
G1 X81.923 Y79.437 E5.06669 F1800.000
G1 X85.000 Y78.643 E5.16103

Cant see anything wrong with the slicer code.

Can you post your config.h pls
Allso check the eeprom settings, see if there is any Z offset listed

I'm not sure where to check the eeprom setting but I did attached the configuration. file.

Edited 1 time(s). Last edit at 02/07/2017 10:31PM by JustinTimeToo.

Why is there 2 discussions about the same issue?

Quote

// Offsets to the probe relative to the extruder tip (Hotend - Probe)
// X and Y offsets must be integers
#define X_PROBE_OFFSET_FROM_EXTRUDER -25 // Probe on: -left +right
#define Y_PROBE_OFFSET_FROM_EXTRUDER -29 // Probe on: -front +behind
#define Z_PROBE_OFFSET_FROM_EXTRUDER -12.35 // -below (always!)

Allthough you say you don't use auto bed leveling, i am wondering if maybe the above offsets are having an effect.
Try setting them to 0

You will have to update them in eeprom

You can use 'repetier host' to edit the eeprom
or send
M502
M500

to read config and save tp eeprom

obewan, I appreciate your persistence in trying to help me.

I carefully checked the excess drop and it's 2.6mm. I also ran a M501 command to read the eeprom. Here is the readout:

SENDING:M501
echo:Hardcoded Default Settings Loaded
echoteps per unit:
echo: M92 X98.50 Y99.50 Z3200.00 E25.00
echo:Maximum feedrates (mm/s):
echo: M203 X300.00 Y300.00 Z15.00 E25.00
echo:Maximum Acceleration (mm/s2):
echo: M201 X3000 Y3000 Z100 E10000
echo:Acceleration: S=acceleration, T=retract acceleration
echo: M204 S3000.00 T3000.00
echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
echo: M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
echo:Home offset (mm):
echo: M206 X0.00 Y0.00 Z0.00
echoID settings:
echo: M301 P22.20 I1.08 D114.00

As you can see the offset is 0.

I'm open to suggestions on where else to look.

I may have to resort to a 'dirty' solution. I may install a Hall effect limit switch on the Z axis and set the Z0 at 2.6mm above the bed. With the Hall effect the gantry can move below the switch without hitting it and therefore start printing at the correct height. As I've said, dirty but it may work since I can't find the real cause for the problem.

Edited 1 time(s). Last edit at 02/08/2017 12:46PM by JustinTimeToo.

I now know for sure it's a software problem but I don't know where. I flashed Marlin 1.1 RC8 and the problem is gone. It starts printing at the set height just as you would expect. That means that the problem was not in the physical printer but the software. I have two optical switches coming but I guess I would not need them.

None the less, it still bugs me that I couldn't find the problem in Marlin.

Thats why i use repetier atm