Why have I started to get "endstops hit: Z" after G29?

My setup:
Prusa i3 look-alike
RAMPS controller
E3Dv6 hot-end
DC42's IR height sensor

Up until a few weeks ago this printer was working perfectly - for every print, G28 homed everything nicely, G29 did it's thing, and then the print went on as normal. Now, at the end of G29's business, it reports "endstops hit: Z" and then repeats G28 & G29 once more. After the second G28/G29 sequence the rest of the print will be performed as normal.

To eliminate any startup script problems I sent both commands directly from the command line - and got the same error message at the end. This means that it's a firmware or hardware problem on the printer, but I cannot work out why this has started to happen. I have not changed the RAMPS code for many months, I can see no physical damage, loose plugs, or similar, and the basic geometry of the printer is just the same.

Could someone please give me a few clues about what to investigate? I'm confused!

Cheers,
David

Maybe a bit of the bed has developed a dip so that probing goes so low that the Z endstops are hit before the probe triggers?
It might have been on the edge before and so only a few fractions of a mm made the difference.
Or possibly (just noticed you are using IR Z probe) you have ended up with a non IR reflective patch or a point where the wires are flexed in such a way that a bad crimp comes into effect?
I'd try jogging Z down until the sensor LED just goes on, and then move around X and Y to see if it stays on all over the bed.
If it goes out then see how far down in Z you have to move to relight it, then check Z endstop value with an M119.

Cheers,
Robin.

Thanks Robin,

I'll give that try next time I wheel the printer out.

Time to bring this back up once more...

I've tried everything - the bed is level, it's a flat glass plate (I've checked it, and swapped it 'just in case'), the bed glass has been cleaned, and the zero height has been checked and adjusted.

I'm confused, because the IR probe IS the Z end-stop - the bed levelling action takes the head and its probe down to the bed in 9 places, each probe seems fine and normal, and it's only the first pass that fails (the second pass almost always works OK). This is a recent problem as this printer has been working for several years with no issues, but I haven't changed anything - hardware or firmware.

I'm puzzled...

So the first pass always fails but subsequent passes work? Could it be the default state of the z end stop is wrong and it's being reset to what it should be after it fails or something of that nature? This sounds a bit too specific and consistent to me for a hardware bug (if that makes sense?).

Have you tried changing the surface (i.e. not a glass plate?). I know glass is opaque to IR and all but still, I've heard of them sometimes being problematic with IR sensors. Try putting a sheet of paper or something on the print bed and running G28 and G29 again.
While it's doing its thing, have a look at the nozzle height, could it be the gantry has gone so far out of parallel with the bed that the nozzle is preventing the IR probe from getting close enough to the bed to trigger properly? I3s can have the gantry skew like that when the z motors go out of sync.
Another thing to check would be to manually jog it around to the probe points like Zedsquared has suggested and check the endstop status at each point. Are there any "troublesome" spots?
Could it be the sensor is starting to fail for whatever reason? Try replacing it (wires and all) with a plain old (working) end stop, just tape it to the effector for testing purposes and have it run again. This should isolate the sensor as the issue.

Just trying to troubleshoot here, some of these may be stupid ideas.

Quote
Trakyan
So the first pass always fails but subsequent passes work? Could it be the default state of the z end stop is wrong and it's being reset to what it should be after it fails or something of that nature? This sounds a bit too specific and consistent to me for a hardware bug (if that makes sense?).

That makes sense, and matches what I was thinking.

Quote

Have you tried changing the surface (i.e. not a glass plate?). I know glass is opaque to IR and all but still, I've heard of them sometimes being problematic with IR sensors. Try putting a sheet of paper or something on the print bed and running G28 and G29 again.

Why would it always fail on the first pass, then work on the second, every time? I use these IR sensors on both of my machines, both over glass, with a black sheet of paper underneath. I'll try a different surface though, just for the hell of it.

Quote

While it's doing its thing, have a look at the nozzle height, could it be the gantry has gone so far out of parallel with the bed that the nozzle is preventing the IR probe from getting close enough to the bed to trigger properly? I3s can have the gantry skew like that when the z motors go out of sync.

Oh, I've knocked the gantry askew so many times! As it happens, I had to reset it just before my last few runs, but it made no difference to the results.

Quote

Another thing to check would be to manually jog it around to the probe points like Zedsquared has suggested and check the endstop status at each point. Are there any "troublesome" spots?

The IR probe is the one and only Z endstop - it is intended to trigger when probing the bed. The idea of a poor joint or broken wire is fine, but I come back to the problem of why it always fails the first time, and always works on the second pass. This happens at every start when I run a sequence of prints, so it's not a matter of a cold machine that's warming up or a bad joint that gets moved enough to connect.

Quote

Could it be the sensor is starting to fail for whatever reason? Try replacing it (wires and all) with a plain old (working) end stop, just tape it to the effector for testing purposes and have it run again. This should isolate the sensor as the issue.

Again, why only on the first pass?

However, I do hear what you say - I might refit the old inductive probe and try it without the glass, to see what happens. I think your first comment regarding something getting reset after the first pass sounds most plausible.

Quote

Just trying to troubleshoot here, some of these may be stupid ideas.

Cheers, and thanks for these suggestions - at least it makes me think!

I can't explain why it's happening only on the first pass, I can speculate but it would mostly be crazy scenarios leading to inconsistent results, which do happen but are usually "never would have guessed" type scenarios.

Also, can you describe in some more detail how it is failing? Is it pausing in the middle of the bed leveling sequence when it hits a troublesome spot? Is it crashing into the bed then throwing an error? Or is the bed leveling completing seemingly "as normal" just with an error being thrown up instead of it working. I didn't quite get the "failure mode" from your OP.

Also, can you clarify when it's failing? Does it ALWAYS fail the first time? And if I'm understanding correctly it MOSTLY works the second time? Not trying to nitpick, just trying to get clear if it is a consistent error or not entirely consistent error. To me, less than consistent errors point to hardware. That and you mentioned that you didn't change firmware when this started happening so I can't imagine that being an issue, unless the chip is failing? My advice is just to debug and narrow down the cause, test each component individually and even if you don't find out why it's not working you'll find out what isn't working.

Edited 1 time(s). Last edit at 08/23/2018 06:47AM by Trakyan.

Quote
Trakyan
Also, can you describe in some more detail how it is failing? Is it pausing in the middle of the bed leveling sequence when it hits a troublesome spot? Is it crashing into the bed then throwing an error? Or is the bed leveling completing seemingly "as normal" just with an error being thrown up instead of it working. I didn't quite get the "failure mode" from your OP.

The third one - the bed levelling completes, an error is flagged, then the printer does the G28/G29 sequence again. After the second pass it proceeds as normal. This makes me think that the printer is starting with something set incorrectly that gets reset to the correct state for the second pass. Not yet sure what that 'something' is yet.

Quote
Trakyan
Also, can you clarify when it's failing? Does it ALWAYS fail the first time? And if I'm understanding correctly it MOSTLY works the second time? Not trying to nitpick, just trying to get clear if it is a consistent error or not entirely consistent error. To me, less than consistent errors point to hardware. That and you mentioned that you didn't change firmware when this started happening so I can't imagine that being an issue, unless the chip is failing? My advice is just to debug and narrow down the cause, test each component individually and even if you don't find out why it's not working you'll find out what isn't working.

Always the first time, on only 1 occasion it has failed on the second pass (out of many 10's of prints).

I'm still investigating, using your previous suggestions and those from others. At the moment it's a matter of finding the time to get stuck in there...

OK - I've been suffering from some confusion, I think. Disregard anything I've said earlier and base any comments on what's written below.

I've just started to attack this problem by running the machine without filament so that I can do G28 & G29 with no complications. Now that I've done that (again) I have come up with the following conclusions:

• The IR sensor is initialising correctly (2 flashes) so it thinks it's working properly (not conclusive, but it helps).
• The nozzle height has been reset and it's currently good.
• The 9 test points are well within the bed surface (i.e. I'm not testing off the bed, or over a clip).
• G28 homes the bed as expected.
• G29 tests the 9 points properly, and the logs show that values are reasonable.
• I get the error "endstop hit: Z" every time I run G28 and G29.
• The "it works OK at the second attempt" I believe is because of something that Repetier-Host was doing - perhaps it was responding to the error and trying again? Don't know the answer to that one.
• I do not get a second attempt when I use Pronterface to send a file - it logs the error shown in the RAMPS screen, then continues with the print.

Here's the log from Pronterface:

Bed x: 10.00 y: 50.00 z: 0.53
Bed x: 100.00 y: 50.00 z: 0.36
Bed x: 190.00 y: 50.00 z: 0.03
Bed x: 190.00 y: 120.00 z: 0.68
Bed x: 100.00 y: 120.00 z: 0.79
Bed x: 10.00 y: 120.00 z: 0.74
Bed x: 10.00 y: 190.00 z: 0.98
Bed x: 100.00 y: 190.00 z: 1.21
Bed x: 190.00 y: 190.00 z: 1.31
Eqn coefficients: a: -0.00 b: 0.01 d: 0.04
planeNormal x: 0.00 y: -0.01 z: 1.00
echo:endstops hit:  Z:1.31

It does show that the bed is a little higher at the back, but this has always been the case - auto-levelling has always compensated for this (I know, I should fix it...)

So I'm now trying to tackle a simpler issue: why the error has appeared after several years of working properly. I'll try out some of the suggestions listed above - watch this space! (If you're not too bored).

Edited 2 time(s). Last edit at 08/27/2018 10:42AM by David J.

Minor update: I'm starting to think it's something to do with Repetier-Host - I have had a few updates lately. Alternatively, it might be the way I'm using it...

If I slice the STL file with my stand-alone version of Slic3r and feed it through Pronterface, the error doesn't appear on the printer's screen. It does appear on the Pronterface log, but that software doesn't consider that it's important and continues with the print - as it should.

If I slice using the Repetier-Host version of Slic3r (or Cura), save the gcode file and feed that through Pronterface, I get the old error again and the printer repeats the G28/G29 commands as before.

I have looked at the beginning of both gcode files but I can't see anything wrong with the opening lines. However, I intend to spend more time comparing the files in the near future.

Me? I'm currently baffled, but continuing to investigate.

Edited 1 time(s). Last edit at 08/27/2018 12:03PM by David J.

Right - I'll start with an apology regarding this flurry of posts!

This is the start of the gcode file generated by my stand-alone slic3r:

; generated by Slic3r 1.2.9 on 2018-08-27 at 16:43:05

; 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 S60 ; set bed temperature
M104 S200 ; set temperature
G28 ; home all axes
G29 ; Autolevel
G1 Z20 F500
M109 S200 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion

As you can see, nothing controversial - it may not be the best, but it works.

Now here is what I see in Repetier-Host's gcode editor when I slice something there:

M107
M190 S60
M104 S200
G28
G29
G1 Z5 F5000
M109 S200
G21
G90
M82
G92 E0
G1 E-0.8 F2400
G92 E0

Much less waffle, but it looks OK with no sign of problems.

Now this is what I get when I save the gcode file in Repetier-Host and pick the option "Add start and end gcode" - this is for copying to a SD card and printing directly:

G28
G29
G1 Z20 F500
M107
M190 S60
M104 S200
G28
G29
G1 Z5 F5000
M109 S200
G21
G90
M82
G92 E0
G1 E-0.8 F2400
G92 E0

Here you can see that the start code has been added twice - which would match the behaviour of my printer exactly when it is run directly. It looks like the endstop error message was a red herring, and the problem may well be the way R-H is assembling its gcode before printing. My next step is to see if I can pipe R-H's output to a file to confirm that it is sending duplicate code.

The investigation continues...

Edited 1 time(s). Last edit at 08/28/2018 09:30AM by David J.