Z-end stop being ignored for prints

I'm trying to get my first print to work. I've done a bunch of alignment and setup the end stops so the auto-home function works perfectly. I used Slic3r to slice up a small calibration piece, got PLA to manually extrude, but then when I hit "print", the first real printing it does is past the Z-end stop scraping against the glass. Here's the start of the G-code from that came from slic3r:

G21 ; set units to millimeters
M107
M190 S65 ; wait for bed temperature to be reached
M104 S185 ; set temperature
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle
M109 S185 ; wait for temperature to be reached
G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion
G1 F1800.000 E-1.00000
G92 E0
G1 Z0.350 F7800.000
G1 X78.077 Y71.237 F7800.000
G1 E1.00000 F1800.000
G1 X78.737 Y70.577 E1.08633 F540.000
...

It does the G28 "home" perfectly and then I can see it do the "lift nozzle" step and it lifts the nozzle the correct amount and in the correct direction. I can see it doing the M109 waiting for temp in the hot end, but then something causes the Z axis to go down past the end stop before the head is moved into the center for printing. I can't see anything there that should do this unless something causes the Z axis scale to be messed up.

I haven't tested it yet (will single step through this code tonight), but I'm guessing it happens with the "G1 Z0.350 F7800.000" line. It doesn't make any sense because the Z axis should be at 5mm, and then going down to a small but positive number should still be fine. But no matter what the scale or anything it should always stop when it hits the limit switch, right? If the limit switch doesn't indicate a limit, then what's the point?

The fact that the limit switch doesn't appear to be stopping it would make me think that the firmware is wrong somehow, but the G28 works perfectly sensing the limit switch just as it should and when I manually move the Z-axis into the limit switch (to the 0 location) it detects the switch. I did notice that after canceling the print the "zero" point for Z is wrong and it won't stop at the limit switch even for manually moving the axis until I manually move it to where the limit switch is not triggered then do a G28. So is there some other setting I'm missing (in slic3r or something) that is reading the limit switch backwards? Any ideas on what to check?

Thanks for the newb help. --Bret

I had the same problem with mine. Did you happen to be using the 3DPrinterCzar Prusa i3 configuration.h file? It has "auto bed leveling" turned on, which causes homing to work differently.
For me, homing the Z-Axis individually worked fine. Using the "All-Home" command is the only portion that implemented the auto bed leveling logic and caused the extruder to hit the glass.

Another way to test is to move the extruder up 20-30MM off the glass. Run the homing code, and manually press the homing switch. Send whichever M code gives you the current X-Y-Z position and see if the Z isn't wrong. The auto bed leveling code believes the switch is 7 or 8 MM below the nozzle, and sets the Z position accordingly.

BTW, I reported this error to 3dPrinterCzar on May 4. They still have not fixed their Configuration.h file on their website.

BTW, I reported this error to 3dPrinterCzar on May 4. They still have not fixed their Configuration.h file on their website.

Thanks for the idea mappler. It was an interesting possibility, but I'm using the main github release of marlin and I checked and the auto-bed leveling stuff is disabled. But the idea of getting the reading of the XYZ positioning regularly helped me pin down the issue.

I took just the top of the g-code file and tested it out a few times. When run slowly (typed in by hand) it didn't exhibit the problem. But when run at normal speed I pinned the problem down to the step that raised the head by 5 mm. Instead of going up 5mm, it would go up by 1 or 2 and then the z-stepper motors would chatter for what would be the rest of the 5mm movement. At this point it thought the head was 5mm off the platform, but it was really only 2mm up so when it moved back down for the print it went "through" the platform. If I used paste correctly I could put the commands in the console and get the same behavior with just a G28 followed by a G1 Z5. I commented out the G1 Z5 and the print went just fine (well, with a few fine tuning steps still to be done). So the Z-axis worked for smaller movements during the build but that 5mm movement up at the start seemed to give it a problem.

In playing with the G28 + G1 Z5 a bit more, I was able to make it work consistently if I "helped" the stepper motors by pushing "up" on the X-axis. I had also never noticed this problem using the "manual" axis movements which gave me a few ideas on how to address this. Here are some different ideas:

1. Stepper Motor Driver Tuning - I have the Pololu's all tuned for 0.28V Vref as suggested for a max 0.7A for 1A rated steppers. I could bump this up (or down) a bit if the probable seems like it is a current issue of some kind. I do have heat sinks on the Pololu's and none of them seem to be getting very hot.

2. Z-speed - I looked at the manual movement speed in pronterface and it's set to 200mm/min or 3.33 mm/sec. The default setting in marlin (which is where it's at now) is 5mm/sec for Z-axis movement. I could drop this down to 3 in marlin and see if that fixes the problem.

3. Z-axis nuts - I have normal X-axis ends with 2 nuts and springs in between. Currently these are fairly tight with the top nut about a hole nut down from the top (i.e., I could fit a second nut in there below the top of the X-end). Is that too tight? Could that be causing the Z-axis motors to be working too hard somehow?

Any other ideas of why my Z-axis motors would be "chattering" instead of actually moving for the last half of the G1 Z5 command? Which of these above ideas do you think is most likely the issue?

Thanks,
Bret

I'm glad it got you on the right track..
I'd experiment with both #1 and #2. Both seem likely to solve your problem to me.

-Matt

Thanks Matt. I'll play around and see what solves the problem. (only change 1 variable at a time and test :-)).

I did come up with another question. Don't the end stops work at other times besides when homing?

Yes the Z-axis got confused by 3 or 4mm when it didn't actually go up but thought it did. But when it went back down to try to go to 0.35, it definitely hit the end stop and triggered it but just kept going. Why doesn't the arduino notice the end stop was hit and stop it from going farther? As I only have single end stops on each axis one direction for each must just be calculated. But the other direction could be protected by the limit switch. Is it just easier to have both directions the same other than homing?

I believe this is related to this setting here:
#define min_software_endstops false // 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.

If I understand these settings correctly, this allows you to move the print head BELOW the position it homes to. I think it ignores the endstops after homing if this is set to "false"

-Matt

Interesting. Both of these are set to "true" in my marlin config. I think these are just the software controls and that it just indicates that it will not tell the motors to go below what it believes are the 0 values. I've seen this behavior at times when I power it up with the head in a strange position. it won't go far in some directions until I do a "Home" on it so it resets the "0" positions. So I think it prevents it from SW telling it to go past what SW thinks are the limits, but it didn't seem to affect the usage of the physical end stop. I guess that's only utilized when homing.

OK, I think I have the problem solved. After repeating the problem last night I noticed that the Z-axis were squeaking quite a bit when turning so I used a very little light oil on them to smooth things out. That seemed to help which indicated that the motors were just working too hard for the speed/current settings. I considered upping the current from the drivers but decided that the Z-axis speed really wasn't that critical and the motors just sounded happier when running at the slower 3.33 mm/s from the manual setting so I changed the max speed setting for normal operation to 3.5mm/s and the problem was resolved. I'll keep an eye on it to see if it shows up again, but I think the problem is fixed. Now I just need to get on with the rest of the calibration. Thanks!

Hi mappler,
Sorry to interupt on this thread, but i have the same exact problem as you. I have the prusa i3 from 3dPrinterCzar with their firmware. The homing command give me a Z value of 10.88 each time instead of 0. In Slic3r i have to issue a G92 Z0 after the G28 ; home all axes for the extruder not to crash on the bed.
Do i just need to turn auto bed leveling off on the firmware to resolv this ? Did you had any answer from 3dPrinterCzar regarding this issue ?
Thanks a lot!

Yes, you just have to turn OFF auto bed leveling. It should NOT have been turned on in the first place. They did not provide a configuration file that would have ever worked with their printer. I reported this to them, they confirmed it was an issue, and told me they would fix it. I'm not sure why they have not updated their website with the correct file.