Disregarding triggered end stop during print

I have just build a Prusa i3 (kit from 3D Printer Czar) and are now in the process of calibrating it. Am trying to start the first ever print with it, but it won't work.
The problem is that the z axis endstop is triggered but disregarded during printing. So after all axis have gone to home, including the z axis that hits the endstop and does the bounce, the extruder position itself to start printing but when it moves down it disregards the z axis endstop and moves straight into the bed and tries to continue...

What can cause this problem?
Because when I move it to home all axis end stops hits, triggers and bounces and stops. It's when I try to print it moves straight into the bed.

The printer has RAMPS 1.4 with Marlin and I use Slic3r and Repetier. Have tried with both Kisslicer and Cura, but I get the same problem there to.

Great big thanks for any help I can get.

Best regards
Roberth

Edited 1 time(s). Last edit at 07/27/2014 05:47PM by Roberth.

Hey,

I also bought a i3 from the Czar and I am having the exact same problem.

Homing seems to work, then when printing, it's, "Dive Captain Dive", right into the bed.

Z endstop set at minimum position.

Everything else seems pretty cool and 3dprinterczar.com replaced some parts broken in transit straight away.

peace,

flyCouch

It almost sounds like there's a z offset set in EEPROM, which is usually used for auto bed levelling. I take it these printers don't come with a z probe for ABL, right? Is auto bed levelling enabled in your Configuration.h?

If not, then maybe try and reset the EEPROM to clear out any bad settings. Manually run an M502 command to restore to the settings in the Configuration.h. Then run M500 to store the settings back to EEPROM.

I feel your pain. I've been battling this same problem for the last 3 weeks
. My band-aide so far was to set the offset in Slic3r to +0.2
Sometime it will leave the HE a little too far from the glass and forcing me to adjust on the fly but its better than watching my hot end grind its way into and across the glass.
I have a Prusa i2 with the usual RAMPS sourced from various places so I don't think this is inherent to your set-up. I didn't have this problem until I updated the pronterface & Sli3er about the time this all started,

Edited 1 time(s). Last edit at 07/28/2014 08:31PM by Shank man.

Quote
flycouch
Hey,

I also bought a i3 from the Czar and I am having the exact same problem.

Homing seems to work, then when printing, it's, "Dive Captain Dive", right into the bed.

Z endstop set at minimum position.

Everything else seems pretty cool and 3dprinterczar.com replaced some parts broken in transit straight away.

peace,

flyCouch

Yea, exept that it seams like a great kit and printer. The service from them has also med phenomenal! They have responded to all my questions fast. Same with this, I have not tried it yet but maybe it helps you somewhat. Here's their answer:

Quote
Han
Usually after calibrating the printer, we will disconnect first, then connect and print. One possibility for your problem might be that you skip the disconnecting part. However, we don't use the z axis endstop very often, so we forward your question to our engineer for further discussion.
If you have any additional questions that we can help, please don't hesitate to ask.

Best,
Han
3D Printer Czar

Thanks to both brucehvn and Shank man for your suggestions. I'll try them as soon as I can.

The endstops are (usually) only used during homing. During printing, you can crash right through them. I'm more concerned about why your head is moving down. That shouldn't happen. Once it's homed, it's at position 0 and it should not need to go below that point. Does your G Code have an instruction to move to a negative Z height? That's the only thing I can think of that might be causing this.

hey all,

had my Z Min Pos set at 5, boom, that did it, when fixed, no more

thanks for your consideration,

flyCouch

Quote
brucehvn
It almost sounds like there's a z offset set in EEPROM, which is usually used for auto bed levelling. I take it these printers don't come with a z probe for ABL, right? Is auto bed levelling enabled in your Configuration.h?

If not, then maybe try and reset the EEPROM to clear out any bad settings. Manually run an M502 command to restore to the settings in the Configuration.h. Then run M500 to store the settings back to EEPROM.

No, it doesn't come with a probe for ABL. But ABL is enabled in the configuration.h that I got from 3DPrinterCzar.
I commented ABL in the Marlin firmware so that it was disable and THAT WORKED! It no longer dives into the bed.

Thank you bricehvn!

Thanks jbernadis. There was some custom default g-code in slic3r that was causing this problem. I didn't put it there

G1 Z5 F5000; lift nozzel

It seems to have lowered the nozzel instead of lifting. I didn't try changing the 5 to a -5 but just.
deleted this line and my diving h.e. problem is gone. Although I am really not sure why but at least printing is fun again.

It would be interesting to see the first 50 or so lines of g code, with some indication of where the offending line was. I'd like to try to figure out why a positive move would cause the head to move down.

It is under the printer settings tab in slic3r

In the Start G-code. It must be part of my recent slicer upgrade. I didn't have this problem before.all I know it without this command my H.E. no longer plunges after I hit print . you got me to look in the right place

I don't see anything about that to cause downward motion. It's not a good preamble though; it should assert absolute coordinates and metric measurements. That code is improperly making assumptions.

I actually just built a printer from 3dprinterczar as well and had the same issue with the Z axis crashing into the bed on printing. It turned out that auto bed leveling was enabled in the default marlin firmware which was causing this.

Edit your configuration.h and disable auto bed leveling, that should fix it. (assuming you don't have an auto leveling setup).

Edited 1 time(s). Last edit at 08/20/2014 08:37AM by cmolson.