Keen to hear how this ended up playing out !

Rincewind wrote:

RepetierHost is pretty smart and knows where you are and doesn't allow manual moves beyond the limits; but with pronterface you can see that you can still ram into the endstops if you are not careful

Oh yes, totally agree. But you still can't go *past* the switch, even with pronterface. If the switch is set fully on at z-stop 0.. it will still smash into only z-stop 0. And yes, the switch lever has about 1mm of travel, but its a constant distance.. so again, 0 remains 0... So if the distance is set correctly, and the bed is properly level.. then zero remains a constant and you can't physically get to -Z1 for example...

What I mean is that the switch has 1mm of travel after being hit. And the firmware doesn't stop you if you want to go to Z-1. So it's not physically impossible to go there...

The fact that nlancaster has no gcode that would cause this effect makes this only a hypothetical possibility though.

RepetierHost is pretty smart and knows where you are and doesn't allow manual moves beyond the limits; but with pronterface you can see that you can still ram into the endstops if you are not careful

Oh yes, totally agree. But you still can't go *past* the switch, even with pronterface. If the switch is set fully on at z-stop 0.. it will still smash into only z-stop 0. And yes, the switch lever has about 1mm of travel, but its a constant distance.. so again, 0 remains 0... So if the distance is set correctly, and the bed is properly level.. then zero remains a constant and you can't physically get to -Z1 for example...

Thats whats so interesting about this particular issue that keeps me intrigued.

The only way to end up with the bed Above the bottom of the nozzle is if you have an off z tab. You cannot move the platform with ANY g-code of ANY sort above the limit switch - thats its job!!

I agree that in this specific case the problem is with 99.9% confidence purely hardware. But just to clarify one small thing: the microswitch still allows maybe 1mm travel after being hit and before breaking, and an interesting fact to know is that in the firmware that we all use, the endstop switches are not actually treated as endstops, but just as homing switches, meaning that the firmware will still allow moves beyond them. This is because in configuration_adv.h we have this:

#define ENDSTOPS_ONLY_FOR_HOMING

RepetierHost is pretty smart and knows where you are and doesn't allow manual moves beyond the limits; but with pronterface you can see that you can still ram into the endstops if you are not careful

The issue is simply as has been described - that corner is not levelled or your rods are bent at the extents of travel.

Set your z-height using ONLY that corner, and your problem will disappear.  Then you can start chasing the underlying issue of why your bed or glass plate is warped or if it is as Ronsii rightfully suggested, bent rods.

Seriously - I doubt theres a mystery here... if you set z-tab to 0 on that corner, voila... problem resolved. It is violating all known laws of physics otherwise, plain and simple Maybe you've got a quantum-string-theory printer

I know you are convinced there is some other issue here - but really - there is no physically possible alternative explanation for you. It is also 100% not software or g-code related.

Set you Z-Tab to Zero on that corner and that corner only AFTER you have levelled the bed, and you'll be laughing... then you can start playing with straight edges and dial gauges....

And remember - Glass despite its appearances is not guranteed to be flat..

The only other thing is - which is pretty darn out there - perhaps you are stuck setting your z-ofset on a section of badly threaded rod. Stick something under your bed to cause you to have to set it all with a lower z-stop... this will change the section og 5/16" rod you are trying to call 'home'... perhaps its randomly getting caught with horrendous backlash at that spot.... which is why the second moves appear to be fine but the first move is off... But this still doesn't fit with the scenario of Z-Stop 0 is 0... there is no -Z1.....

Also Notice  ;G1 E7; extrude anchor is commented out in my gcode, when this was enabled. The hotend would be rammed into the bed enough to deflect the entire wood bed holder assembly.

I haven't watched the video yet.. but the more you speak of things, the more I have to insist that your bed isn't flat and level.

On how many sides and where do you have your clips. 3 or 4 sided ?

I use G1 E7 religously with my Glass and much much thicker (and therefore, would exacerbate the problem you describe) ceramic tile... No issues. The only time I have remotely gotten close to the scenario you describe, is when the rear of my bed is not level, and protrudes above the center of the bed where I set my Z-Stop against.

Nope no z-offset applied in either kisslicer or slic3r.

I meant to post this earlier but figured there was no chance of this being an issue.

Down, the z-scew is not missing.  The printer prints perfectly fine.  Just at z-home the tip of the extruder is below the level of the bed.  Before I had glass, I hit the edge of the bed several times as well, even when it was printing fine.

The reason I am so concerned about what is happening is, that I wish to build a new bed/glass holding system and It may protrude into this area.

Adrian there is a video above downeastas posts that shows it hitting hte glass. This is after running a print that came out perfect.

Cool - I'll have to catch it in a few hours. Youtube/Vimeo no work from where I presently am (hence why I can't even see it without source-viewing the page )

I still dont understand why your your z stop hasnt limited your printer from raising the bed so high.  Is the z screw missing?

Adrian there is a video above downeastas posts that shows it hitting hte glass. This is after running a print that came out perfect.